f 

* 



ETSI TS 101 267 V8.3.0 (2000-08) 



xp-002222021 



Technical Specification 



P.O. I 



* n 



Digital cellular telecommunications system (Phase 2+); 
Specification of the SIM Application Toolkit for the 
Subscriber Identity Module - Mobile Equipment 

(SIM - ME) interface 
(GSM 11.14 version 8.3.0 Release 1999) 



.GLOBAL S YSTEIV^^f 
MOBIIiE COMMUNI<l 





V .7 ... ..i 




(GSM 11.14 version 8.3.0 Release 1999) 

ETSI TS 1 01 267 V8.3.0 (20d0-08) 



Reference ■ 
RTS/SMG-09 rn4Q8R2~ 

Keywords 



ETSl 



Tel.: .33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 



Important notice 



editor@etsi.fr 
Copyright Notifteati^ 



SNSDOClD: <XP_2222021A_ ( > . £ TS/ 



(GSM 11.14 version 8.3.0 Release 1999) 



3 



ETSI TS 101 267 V8.3.0 (2000-08) 



Contents 

Intellectual Property Rights 8 

Foreword 8 

1 Scope 9 

2 References 9 

3 Definitions, abbreviations and symbols 1 2 

3. 1 Definitions 12 

3.2 Abbreviations 13 

33 Symbols 14 

4 Overview of SIM Application Toolkit : 14 

4.1 Profile Download 14 

4.2 Proactive SIM 14 

4.3 Data download to SIM 15 

4.4 Menu selection , 15 

4.5 Call control by SIM 15 

4.6 MO Short Message control by SIM 15 

4.7 Event download : 1 5 

4.8 Security 15 

4.9 Multiple card 15 

4. 1 0 Timer Expiration 15 

4. 1 1 Bearer Independent Protocol 16 

5 Profile download 16 

5.1 Procedure 16 

5.2 Structure and coding of TERMINAL PROFILE 1 6 

5.3 Definition of display parameters in Profile download 1 9 

5.3. 1 Number of characters supported down the ME display \ 1 9 

5.3.2 Number of characters supported across the ME display 1 9 

5.3.3 Display can be resized 20 

5.3.4 Text Wrapping , 20 

5.3.5 Text Scrolling 20 

5.3.6 Width reduction when in a menu 20 

6 Proactive SIM 20 

6.1 Introduction 20 

6.2 Identification of proactive SIMs and of ME support 22 

6.3 General procedure 22 

6.4 Proactive SIM commands and procedures 23 

6.4.1 DISPLAY TEXT 23 

6.4.2 GET IN KEY 24 

6.4.3 GET INPUT 25 

6.4.4 MORE TIME '. 26 

6.4.5 PLAY TONE ^...26 ~ 

6.4.6 POLL INTERVAL 27 

6.4.7 REFRESH 27 

6.4.7. 1 EFjmsi changing procedure 28 

6.4.8 SET UP MENU 28 

6.4.9 SELECT ITEM : 29 

6.4. 10 SEND SHORT MESSAGE 30 

6.4.11 SENDSS 31 

6.4.12 SENDUSSD 32 

6.4.13 SET UP CALL 33 

6.4.14 POLLING OFF 34 

6.4. J 5 PROVIDE LOCAL INFORMATION 35 

6.4. 16 SET UP EVENT LIST ; 35 



SNSDOCID: <XP 2222021 A l_> ETSI 



«™v a ETSI TS 101 267 V8.3.0 (2000*08) 

(GSM 11.14 version 8.3.0 Release 19S9) * 



0 



*6 

6.4. i 7 PERFORM CARD AFOU , ^ 

6.4. 1 8 POWER OFF CARD , ; 

6.4. 1 9 POWER ON CARD ZZZZm' 

6.4.20 GET RHADHR STA TUS : ^ 

6 4.2 1 TIMER MANAGEMENT 

6 '4?2 SET UP IDLE MODE TliXT ■ ; '"'".^ 

6 4 23 RUN AT COMMAND . y 

6424 SEND DTMF M) 

6 4 2S LANGUAGF NO 1 11 K A I ION : 4Q 

6A26 LAUNCH BROWSER. : "* 40 

6.4.27 OPEN CHANNEL ' 42 

6.4.28 CLOSE CHANNH1 42 

6.4.29 RECEIVE DATA ' 43 

64^0 SEND DATA 44 . 

6.4.3 1 CiKT CH ANNFI , STATUS 44 

6.5 Common elements in proactive SIM commands '"' 44 

6.5. 1 Command number 44 

6.5.2 Device identities 44 

6.5.3 Alpha identifier 4 5 

6 5 4 Icon identifiers 4 S 

6 6 Structure or proactive SIM commands ^ 

6At ' DISPLAY TEXT 45 

6.6.2 GETLNKEY 46 

6.6.3 OL- 1 INPUT 46 

6.6.4 MORHTIMK 46 

6 6.5 PLAY TONE 47 

6.6.6 POLL 1 NTH R VAT - 47 

6 6.7 SET-UP MENU ' 48 

6.6.8 SELECT ITEM 48 

6 6.9 SEND SHORT MESSAGE : 4<) 

6.6.10 SEND SS 49 

6.6.11 SEND USSD 49 

6.6.12 SET UP CALL 49 

6.6.13 REFRESH s() 

6.6.14 POLLING OFF 5() 

6 6 15 PROVIDE LOCAL INFORMATION 5() 

6.6.16 SET UP EVENT LIST ^ 

6.6. 17 PERFORM CARD APDU 5() 

6.6.18 POWER OFF CARD : '" 5() 

6 6 19 POWER ON CARD 5 j 

6*6.20 GET READER STATUS 5 , 

6 6 21 TIMER MANAGEMENT 5l 

6.6.22 SET UP IDLE MODE TEXT 5| 

6.6.23 RUN AT COMMAND 5? 

6 6 74 SEND D IME COMMAND 5 ~ 

6625 LANGUAGE NOTIFICATION ^ 

6.6.26 LAUNCH BROWSER 5 3 

6 6.27 OPEN CHANNEL 55 

6 6.28 CLOSE CH ANNFI 55 

6.6.29 RECEIVE DATA : 55 

6.6.30 SEND DATA 5<5 

6.6.3 1 GET CHANNEL STATUS ZZZZZZZZZZZZsS 

6 7 Command results 57 

6 8 Structure of TERMINAL RESPONSE 62 

6 9 Proactive S LM session and ME display interaction 6 ~ 

6. 10 Handling of unknown, unforeseen and erroneous messages ^ 

6.10.1 General ZZZZZZ. 63 

6. 1 0.2 Message loo short ^ 

6.10.3 Missing minimum information ' 63 

6.10.4 Unknown Tag value 



ETSI 



3NSDOC1D <XP 2222021 A_L> 



(GSM 11.14 version 8.3.0 Release 1 999) 5 ETSI TS 1 01 267 V8.3.0 (2000-08) 



6. 10.5 Unexpected Tag value 

6.10.6 Length errors 

6. 1 0.7 Contents not understood 

6. 10.8 Extended length data objects 

6. 1 1 Proactive commands versus possible Terminal response 



7 Data download to SIM 67 

7. 1 SMS-PP data download 67 

7.1.1 Procedure 67 

7. 1 .2 Structure of ENVELOPE (SMS-PP DOWNLOAD) 68 

7.2 Cell Broadcast data download 68 

7.2.1 Procedure 08 

7.2.2 Structure of ENVELOPE (CELL BROADCAST DOWNLOAD) 68 

8 Menu Selection 69 

8 1 Procedure 69 

8/2 Structure of ENVELOPE (MENU SELECTION) 69 

9 Call Control and MO SMS control by SIM 10 

M. I Call Control by SIM '. 7 <) 

*>. I . I Procedure for mobile originated calls 70 

1 .2 Procedure for Supplementary Services and USSD 71 

1 .3 Indication to be given to the user 7 2 

»>. 1 .4 Interaction with Fixed Dialling Number 73 

<4 [ .5 Support of Barred Dialling Number (BDN) service 73 

9. 1 .6 Structure of ENVELOPE (CALL CONTROL) 74 

9.2 MO Short Message Control by SIM 76 

V.2.1 Description 76 

9.2.2 Structure of ENVELOPE (MO SHORT MESSAGE CONTROL) 76 

9.2.3 Indication to be given to the user 77 

10 * Timer Expiration : 77 

10.1 Description 77 

10.2 Structure of ENVELOPE (TIMER EXPIRATION) 77 

1 1 Event download •. 7 § 

I I.I MT call event 7 8 

1 I.I.I Procedure 4 7 8 

1 1 .1.2 Structure of ENVELOPE (EVENT DOWNLOAD - MT call) 78 

1 1 .2 Call connected event 79 

1 1.2.1 Procedure 79 

1 1 .2.2 Structure of ENVELOPE (EVENT DOWNLOAD - call connected) 79 

1 1 .3 Call disconnected event 80 

1 1.3.1 Procedure • 80 

I. 1 .3.2 Structure of ENVELOPE (EVENT DOWNLOAD - Call disconnected) 80 

1 I A Location status event 8 1 

1 1.4. 1 Procedure 81 

I 1 .4.2 Structure of ENVELOPE (EVENT DOWNLOAD - Location status)........ 81 

1 1 .5 User activity event 82 

I I. 5.1 Procedure 82 

I 1 .5.2 Structure of ENVELOPE (EVENT DOWNLOAD - User activity) 82 

1 1 .6 Idle screen available event 83 

1 1.6.1 Procedure 83 

1 1 .6.2 Structure of ENVELOPE (EVENT DOWNLOAD - Idle screen available) ...83 

1 1 .7 Card reader status event 83 

1 1.7.1 Procedure 83 

1 1 .7.2 Structure of. ENVELOPE (EVENT DOWNLOAD - card reader status) 83 

1 1 .8 Language selection event 84 

1 1.8.1 Procedure ..... 84 

1 1 .8.2 Structure of ENVELOPE (language selection) 84 

1 1 .9 Browser Termination event 85 

1 1.9.1 Procedure : -85 



BNSDOCID: <XP 2222021A_J_> ETSI 



. R ETSI TS 101 267 V8.3.0 (2000-08) 

(GSM 11.14 version 8.3.0 Release 1999) * 

. x 85 

j | .9.2 Structure of LNVHl ,OPK (browser termination) ^ 

I i JO Data "available event 85 

I!;!!!'] S^eul^ Data available) ZIIIlll 

11.11 Channel status event ■ S6 

iiit 1 procedure « 0 

' In Structure ofTaNVliLOPU (UVUNT DOWNLOAD - Channel status) 

' K ' 87 

12 SIMPI.J TI.V data objects 87 

12.1 Address 87 

12.2 Alpha identifier SK 

12.3 Called party subaddress H8 

12.4 Capability configuration parameters ..ZZ... 88 

12.5 Cell Broadcast Page Z.".".' 88 

12.6 Command details 92 

12.7 Device identities ™^ZZ 92 ' 

12.8 Duration 93 

12.9 Ttem 93 

12.10 Item identifier 93 

12.11 Response length 93 

12 12 Result 94 

12.12. 1 Additional information for SLND SS C} ~ 

12 12.2 Additional information for Mli problem ^ 

12.12.3 Additional information for network problem "Z..'."..Z5 

12 12.4 Additional information for SS problem ( ^ 

12.12.5 Additional information for SMS problem : . . . Z . Z ".9 5 

12.12.6 Not used 95 

p p 7 Additional information for USSD problem ,""1 96 

p p H Additional information for interaction with call control or MO SM control * 

1?I2 9 Additional information for MultipleCard commands % 

I? p 10 Additional information for Launch Browser problem % 

12.12.1 1 Additional information for Bearer Independent Protocol ZZZZZ.Z97 

12.13 SMSTPDU .....ZZ.*. 97 

12.14 SS string Z.......r.Z 97 

12.15 Text string • 97 

12.15.1 Coding of text in unpacked formal ^ 

P 15 2 Codins of text in packed format ^ 

12.15.3 Coding of text in 16 bus UCS2 alphabet format ZZZZZZ".98 

12.16 Tone 99 

12.17 USSD string ZZ'Z""..'. 99 

12.18 File List ZZZ.Z'.'. \ W 

12. 19 Location Information 99 

12.20 IMiil .".Z/.ZZZ"'. 100 

12.21 Help Request 100 

1 2.22 Network Measurement Results j ()() 

12.23 ' Default Text 100 

12.24 Items Next Action Indicator iqi 

12.25 Event list • 101 

12.26 Cause ^ZZ*'Z"ZZZ". 101 

12.27 Location status ; 102 

12.28 Transaction identifier |0 2 

12.29 BCCH channel list ""'*'" 1() 3 

12.30 Call control requested action "" J03 

12.31 Icon Identifier ; **""" ]Q3 

12.32 Item Icon Identifier list ; j 04 

12.33 Card reader status """ ^4 

12.34 ' CardATR ..105 

12.35 C-APDU • ■"/ 105 

12.36 R-APDU [ 105 

12.37 Timer identifier 106 

12.38 Timer value 



BNSDOCID <XP 2222021 A_l_> 



ETSI 



(GSM 11.14 version 8.3.0 Release 1 999) 7 ETSI TS 1 01 267 V8.3.0 (2000-08) 

1239 Date-Time and Time zone 106 

12.40 AT Command 106 

12.41 AT Response : 107 

12.42 BC Repeat indicator 107 

12.43 Immediate response 107 

12.44 DTMF string 107 

12.45 Language 108 

12.46 Timing Advance 108 

1 2.47 Browser Identity 1 08 

12.48 URL 108 

12.49 Bearer 109 

12.50 Provisioning File Reference 109 

1 2 .5 1 B ro wser Termi nati on Cause 1 09 

1 2.52 Bearer description 109 

1 2.52. 1 Bearer parameters for CSD 110 

12.52.2 Bearer parameters for GPRS 1 1 1 

12.52.3 Default bearer 1 12 

12.53 Channel data 112 

1 2.54 Channel data length 113 

12.55 Buffer size , 113 

12.56 Channel status 1 1 3 

12.57 Card reader identifier 1 14 

12.58 Other Address 114 

12.59 SIM/ME interface transport level 1 14 

13 Tag values 115 

13. 1 BER-TLV tags in ME to SIM direction 1 15 

13.2 BER-TLV tags in SIM TO ME direction 1 15 

1 3.3 SIMPLE-TLV tags in both directions 1 1 5 

13.4 Type of Command and Next Action Indicator 117 

1 4 Allowed Type of command and Device identity combinations 118 

15 Security requirements 1 1 9 

Annex A (normative): Support of SIM Application Toolkit by Mobile Equipment ; 120 

Annex B (informative): Example command sequences for proactive SIM 121 

Annex C (informative): Example of DISPLAY TEXT Proactive SIM Command 123 

Annex D (normative): Structure of SIM Application Toolkit communications 124 

Annex E (informative): ME display in proactive SIM session 125 

Annex F (informative): Help information feature processing 126 

Annex G (informative): Monitoring of events 127 

Annex H (normative): Support of Multiple Card Operation 128 

Annex I (informative): Multiple Card proactive command examples 129 

Annex J (informative): Bearer independent protocol proactive command examples 130 

Annex K (informative): WAP References 132 

Annex L (informative): Change history 133 

History 1 136 



BNSDOCID: <XP 2222021 A i > ETSf 



(GSM 11.14 version 8.3.0 Re.ease 1999) 8 . " ETSl .TS 101 267 V8.3.0 (2000*8) 

Intellectual Property Rights 

Z^oftrSl aunJanh'. which is available iron, the LTSI Secretariat. Kates, upda.es arc-availablc on ,hc ETSl Web 
server ( hiip://www.clsi.ora/ipi ). . 

Pursuant to .he KTSl IPR Policy, no investigation, including IPR searches, has been carried out by ETSl No ^uaran.cc 
STT.il! as to the ex.stence of o.hor .PRs no, referenced in LTSI SR <XX) 3 14 (or .he updates on the h 1 S. Wch 
'server) which arc. or may be. or may become, essential to the present document. ' • 



Foreword 

I Ins Technical Specification (TS) has been produced by the Special Mobile Group (SMC). 

n„ present document defines the in.erlace between the Subscnber Identity Module (SUM) and the ..Mobile Equipment 
• Ml.) within the digital cellular telecommunications system. 

I fl , moments of the present document are subject to continuing work wilhin SMG and may change lollowing .formal 
IsnT^S Should SMC, modify the contents of the present document it will then be republished by MM with an 
uu milying change of release date and an increase in version number as tollows: 

v ersion S.x.y 
where: 

8 indicates (ISM Phase 2-t- Release 1 999. 

x the second digit is incremented for all changes of substance, i.e: technical enhancements, corrections, updates, 
etc.. 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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1 Scope 

The present document defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment 
(ME), and mandatory ME procedures, specifically for "SIM Application Toolkit". 

SIM Application Toolkit is a set of commands and procedures for use during the network operation phase of GSM, in 
addition to those dcimcd in GSM 11.11 [20|. 

Specifying the interface is to ensure interoperability between a SIM and an ME independently of the respective 
manufacturers and operators. The concept of a split of the Mobile Station (MS) into these elements as well as the 
distinction between the GSM network operation phase, which is also called GSM operations, and the administrative 
management phase are described in GSM 02. 17 [3], 

The present document defines: 

- the commands; 

- the application protocol; 

the mandatory requirements on the SIM and ME for each procedure. 

Unless otherwise stated, references to GSM also apply to DCS 1 800. 

The present document does not specify any aspects related to the administrative management phase. Any internal 
technical realization of either the SIM or the ME are only specified where these reflect over the interface. This standard 
does not specify any of the security algorithms which may be used. 

The present document defines an enhancement for GSM Phase 2+ of the SIM/ME interface for GSM Phase 2. While all 
attempts have been made to maintain phase compatibility, any issues that specifically relate to Phase 1 should be 
referenced from within the relevant Phase 1 specification. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

• .• For this Release 1999 document, references to GSM documents are for Release 1999 versions (version S.x.y). 

[1 1 GSM 01.02: ''Digital cellular telecommunications system (Phase 2+); General description of a 

GSM Public Land Mobile Network (PLMN)". 

[2] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[3J GSM 02. 17: "Digital cellular telecommunications system (Phase 2+): Subscriber Identity Modules 

(SIM) Functional characteristics". 

|4| GSM 02.30: "Digital cellular telecommunications system (Phase 2+); Man-Machine Interface 

(MMI) of the Mobile Station (MS)". 

[5] GSM 03.38: "Digital cellular telecommunications system (Phase 2+); Alphabets and 

language-specific information". 
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GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical reali/ai.on of the 
Short Message Service (SMS) Poinl-to-Poinl ( PP.)" . 

GSM 03.4! : "Digital cellular telecommunications system (Phase 2 ; }: Technical realization of 
Short Message Service Cell Broadcast (SMSCB)". 

GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 
3 specification". 

GSM 04. 1 I : "Digital cellular telecommunications system (Phase 2+J: Pomt-to-Pomt (PP) Short 
Message Service (SMS) support on mobile radio interlace". 

GSM 04.80: "Digital cellular telecommunications system (Phase 2+): Mobile radio interface layer 
1 supplementary "services specificaiion: Formals and coding". 

GSM 04.90: "Digital cellular telecommunications system (Phase 2+): Unstructured Supplementary 
Service Data (USSD) - Stage 3". 

GSM 07 0v "Di'Mtal cellular telecommunications system (Phase 2+): Use of Data Terminal 
Equipment - Daw Circuit terminating Equipment (DTP - DCF.) interface for Short Message 
Service (SMS) and Cell Broadcast Service (CBS)". 

GSM (W 9I - "Di'Mtal cellular telecommunications system: [merworking aspects of the Subscriber 
Identity Module - Mobile Equipment (SIM - Mil) interface between Phase I and Phase 2*7 

Not used. 

CCITT Recommendation R. 1 64: "Numbering plan lor the ISDN era". 

ISO/IRC 78 16 3 ( 1997): "Identification cards - integrated circuit(s) cards with contacts. Part 3: 
lilectronic signals and transmission protocols". 

ISO/IRC 7816-6 (1995): "Identification cards - Integrated circuir(s) cards with contacts, Part 6 
Inter-industry data elements'". 

GSM 02-40: "Digital cellular telecommunications system {Phase 2+); Procedures for call progress 
indications". 

GSM 02.07: "Digital cellular telecommunications system (Phase 2+); Mobile Stations (MS) 
features". 

GSM 11.11: "Disital cellular telecommunications system (Phase 2+); Specification of the 
Subscriber Identity Module - Mobile Equipment (SIM - MR) interface". 

pn GSM il 12: "Oiaital cellular telecommunications system (Phase 2): Specification of the 3 Volt 

Subscriber Identity Module - Mobile Equipment (SIM - MR) interface". 

1 2 9 1 GSM 03.22: "Digital cellular telecommunications system (Phase 2+): Functions related to Mobile 

Station (MS) in idle mode". 
p 3J GSM ()4.()7 : "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

signalling layer 3; General aspects". 
(94 | gsm 03.48: "Digital cellular telecommunications system (Phase 2+); Security Mechanisms for the 

SIM application toolkit ". 

1 25] LSO/IEC 7816-4 (1995): "Identification cards - Integrated circuit(s) cards with contacts, Part 4: 

Inter-industry commands for interchange". 

p 6| GSM 02.42: "Digital cellular telecommunications system (Phase 2+); Network identity and 

timezone; Service description; Stage 1 ". 
|271 GSM 07.07: "Digital cellular telecommunications system (Phase 2+); AT command set for GSM 

Mobile Equipment (ME)". 
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[28] GSM 03.22: "Digital cellular telecommunications system (Phase 2+); Functions related to Mobile 

Station (MS) in idle mode and group receive mode". 

[29] ISO 639 ( 1 988): "Code for the representation of names of languages". 

[30 1 3G TS 23.040: "Technical realization of the Short Message Service (SMS); Point-to-Point (PP)". 

[3 i | GSM 02.02: "Digital cellular telecommunication system (Phase 2+); Bearer Services (BS) 

supported by a GSM Public Land Mobile Network (PLMN)". 

[321 IETF RFC i7 ^ 8: "Uniform Resource Locators (URL) : T. Berners-Lee ? ct al., December 1994. 

[33| IETF RFC 768 "User Datagram Protocol (UDP)*'. 

[34| IETF RFC 793 "Transmission Control Protocol (TCP)". 
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3 Definitions, abbreviations and symbols 
3.1 Definitions 

For the purposes of the present document, the following-terms and definitions apply. For further information and 
definitions refer to GSM ()i:.02 | 1 1. 

application: An application consists of a set of security mechanisms, files, data and protocols (excluding transmission 
protocols). ■ ■ 

application protocol: The set of procedures required hy the application. 

bearer independent protocol: Mechanism by which the Mli provides the SIM with access to the data bearers supported 
by the Mli and the network. 

card session: A link between the card and the external world starting with the ATR and ending with a subsequent reset 
or a deactivation of the card. 

card x: Additional card. 

card reader x: Electrical interlace to support additional card. 

data channel: allow the SIM and the network to exchange data using a selected bearer. 

data object: Information seen at the interface for which are defined a tag (identifier), a length and a value. Data objects 
can be either BLR-TLV (objects that conform to the Basic Encoding Rules of ASM. I ) or SIMPLF-TLV. In this 
specification, ail BliR-TLV data objects are "primitive": the value part consists only of SIMPI ,F-TT .V data objects. 

link: Radio Resource. 

padding: One or more bits appended to a message in order to cause the message to contain the required number of bits 
or bytes. 

proactive SIM: A SIM which is capable of issuing commands to the MR within the T-0 protocol. 

proactive SIM session: Sequence of related SIM application toolkit commands and responses. A proactive SIM session 
starts with the status response '91 xx" (proactive command pending) and ends with a status response of VO ()()' (normal 
ending of command) after Terminal Response. 

Rx buffer: A dedicated memory used to temporarily store data to be retrieved. 

Service data unit (SDU): In layered systems, a set of data that is sent by a user of the services of a given layer, and is 
transmitted to a peer service user semanticaily unchanged. A Protocol Control Information (PCI) header is attached to 
the Service Data Unit (SDU) by the layer to form a Protocol Data Unit (PDU). 

SIM application session: The execution of a sequence of commands internal to the SIM that can result in the 
performance of one or several proactive SIM sessions. The SIM application session can be started by any event in the 
card session, and can execute for the duration of the card session. Processing of the SIM application session will not 
interfere with normal GSM operation. 

SIM Application Toolkit: A set of applications and related procedures which may be used during a GSM session. 
Tx buffer: A dedicated memory used to temporarily store data to be sent; 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply, in addition 10 those listed in 
GSM 01.04 [2]: 



A3 


Algorithm 3, authentication algorithm; used for authenticating the subscriber 




A5 


Algorithm 5, cipher algorithm; used for enciphering/deciphering data 




A8 


Algorithm 8, cipher key generator; used to generate K c 




A38 


A single algorithm performing the functions of A3 and AB 




ADN 


Abbreviated Dialling Number 




APDU 


Application Protocol Data Unit 




ATR 


Answer To Reset 




BCD 


Binary Coded Decimal 




BDN 


Barred Dialling Number 




BER 


Basic Encoding Rules of ASN.l 




C-APDU 


Command Application Protocol Data Unit 




CB 


Cell Broadcast 




CBMI 


Cell Broadcast Message Identifier 




CCP 


Capability/Configuration Parameter 




CSD 


Circuit Switched Data 




DCS 


Digital Cellular System 




DTMF 


Dual Tone Multiple Frequency 




EF 


Elementary File 




EGPRS 


EDGE General Packet Radio Service 




ETSI . 


European Telecommunications Standards Institute 




etu 


elementary time unit 




FDN 


Fixed Dialling Number 




GPRS 


General Packet Radio Service 




GSM 


Global System for Mobile communications 




ID 


IDcntifier 




IEC 


International Electrotechnical Commission 




1MEI 


International Mobile Equipment Identity 




IMSI 


International Mobile Subscriber Identity 




ISO 


International Organization tor Standardization 


V 


Kc 


Cryptographic key; used by the cipher A5 




Ki 


Subscriber authentication key; the cryptographic key used by the authentication algorithm, A3, and 




cipher key generator, A8 




lgth 


The (specific) length of a data unit 




LND 


Last Number Dialled 




ME 


Mobile Equipment 




MMI 


Man Machine Interface 




MS 


Mobile Station 




NMR 


Network Measurement Results (see also GSM 04.08 f 8 )) , 




NPI 


Numbering Plan Identifier 




PDP 


Packet Data Protocol, e.g., Ip or X25 or PPP 




PDU 


Protocol Data Unit 




R-APDU 


Response Application Protocol Data Unit 




RAND 


A RANDom challenge issued by the network 




RFU 


Reserved for Future Use 




SAT 


SIM Application Toolkit 




SDU 


Service Data Unit 




SIM 


Subscriber Identity Module 




SMS 


Short Message Service 




SRES 


Signed RESponse calculated by a SIM 




SS 


Supplementary Service 




ssc 


Supplementary Service Control string 




SW1/SW2 


Status Word 1 / Status Word 2 




TCP 


Transmission Control Protocol 




TE 


Terminal Equipment (e.g. an attached personal computer) 




TLV 


Tag, length, value 
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TON 


Type Of Number 


TP 


Transfer layer Protocol 


TS 


Technical Specification 


UDP 


User Datagram Protocol 


UCS2 


Universal two byle coiled Character Set 


URI. 


Universal Resource Locator 


USSD 


Unstructured Supplementary Service Data 



3.3 Symbols 

'()' to V\ and 'A' to 'F The sixteen hexadecimal dibits. 



4 Overview of SIM Application Toolkit 

The SIM Application Toolkit provides mechanisms which allow applications, existing in the SIM, to interact and 
operate with any MI; which supports the specific mcchamsm(s) required by the application. 

If class "a" is supported, a SIM supporting SIM Application Toolkit shall be able to communicate with the additional 
card(s) and get information about the additional reader(s) via the ME. 

The following mechanisms have been defined. These mechanisms are dependent upon the commands and protocols 
relevant to SIM Application Toolkit in GSM I I . I I [20|. 

4.1 Profile Download 

Profile downloading provides a mechanism for the ME to tell the SIM what it is capable of. The Mli knows what the 
SIM is capable of through the SIM Service Table and Iil* pnASr; . 

4.2 Proactive SIM 

Proactive SIM gives a mechanism whereby the SIM can initiate actions to be taken by the ME. These actions include: 

- displaying text from the SIM to the ME: 

- . sending a short message; 

setting up a voice call to a number held by the STM; 

setting up a data call to a number and bearer capabilities held by the SIM; 

- sending a SS control or USSD siring: 
playing tone in earpiece; 
initiating a dialogue with the user; 

- SIM initialization request and notification of changes to KF(s): 
providing local information from the ME to the SIM; 

- communicating with the additional card(s) (if class "a" is supported); 

- providing information about the additional card reader(s) (if class "a" is supported); 
managing timers running physically in the Mli: 

' - running an AT command received from the SIM, and returning the result to the SIM (if class "b" is supported); 

- sending DTMF; 

requesting the Mb to launch the browser corresponding Jo a URL. (if class "c" is supported);, 

- establishing and managing a bearer independent protocol (if class "e" is supported). 

For each command involved in the dialog with the user, a help information may be available, either for each item of a 
list of items proposed to the user, or with each command requesting a response from the user. If a proactive command 
involved in the dialog with the user indicates the availability of the help feature, the support of this feature is optional for 
the Mli. 



BNSDOCID". <XP 2222021 A_L> 



ETSI 



(GSM 11.14 version 8.3.0 Release 1 999) 1 5 ETSl TS 1 01 267 V8.3.0 (2000-08) 

4.3 Data download to SIM 

Data downloading to the SIM uses either dedicated commands (the transport mechanisms of SMS point-to-point and 
Ceil Broadcast) or the Bearer independent protocol. Transfenral of information over the SIM-ME interface uses the 
ENVELOPE command. 



4.4 Menu selection 

A set of possible menu entries is supplied by the SIM in a proactive SIM command. The menu selection mechanism is 
used to transfer the SIM application menu item which has hcen selected by the user to the SIM. The menu selection 
mechanism may also be used for requesting help information on the items of the SIM application menu. 



4.5 Call control by SIM 

When this service is activated by the SIM, all dialled digit strings, supplementary service control strings and USSD 
strings are first passed to the SIM before the ME sets up the call the supplementary service operation or the USSD 
operation. The ME shall also pass to the SIM at the same time its current serving cell. The SIM has the ability to allow, 
bar or modify the call, the supplementary service operation or the USSD operation. The SIM also has the ability to 
replace a call request, a supplementary service operation or a USSD operation by another call request or supplementary 
service operation or USSD operation. For example, a call request can be replaced by a supplementary service operation 
or a USSD operation, and vice- versa. 

4.6 MO Short Message control by SIM 

When this service is activated by the SIM, all MO short messages are first passed to the SIM before the ME sends the 
short message. The ME shall also pass to the SIM at the same time its current serving cell. The SIM shall have the 
ability to allow the sending, bar the sending or modify the destination address of the short message before sending it. 

4.7 Event download 

A set of events to monitor for is supplied by the SIM in a proactive SIM command. The event download mechanism is 
used to transfer details of the event to the SIM, when it occurs. Events that the ME can report to the SIM include 
incoming calls, location status, and availability of the screen for applications. 

4.8 Security 

Applications designed using the features in this specification may require methods to ensure data confidentiality data 
integrity, and data sender validation, or any subset of these. Requirements for these mechanisms are defined in - 
clause 15. 

4.9 Multiple card 

This subclause applies only if class "a" is supported. 

One event and a set of proactive commands are supplied to monitor and control Card x behaviour. 

4.10 Timer Expiration 

The SIM is able to manage timers running physically in the ME with a proactive command. The Timer Expiration 
mechanism is used to inform the SIM when a timer expires. 
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This subclause applies if class "e" is supported. 

The set of proactive commands (OPLN CHAN N Hi .. CLOSE CHANNEL. SF.ND DA TA. RECEIVE DATA and GliT 
CHANNEL STA TUS) and cvenis (Daia available, Channel status) allows the SIM U> establish a data channel with the 
Ml*, and through the MK to a remote Server in the Network. The SIM provides information for the MH to select an 
available bearer at the time of channel establishment. The M Li then allows the SIM and the Server to exchange data on 
ihr.s channel, iransparcnily. The SIM uses service of Mi: lower layer to send data by providing Service Data Unit !o ML. 
The default lower layer is the higher .layer of selected bearer. 



Profile download 



5.1 



Procedure 



The profile download instruction is sent by the Mb to the SIM as part of the SIM initialization procedure. This 
procedure is specified in GSM M . I I [20|. In this procedure, the Mii reads HH,, MASl :. If l£I : mASI : indicates that the SIM 
requires the MR to perform the profile download procedure, then the MH shall, after having performed the CHV l 
verification procedure arid before selecting F.F lM si or LLY< X > send the TERMINAL PROFILE command, as specified 
below, to the SIM. The profile sent by the ML shall stale the facilities relevant to SIM Application Toolkit that are 
supported by the ME. 

This procedure is important, as it is by this that the SIM knows what the ML is capable of, and the SIM can ihen limit ih> 
instruction range accordingly. If no command is sent by ihc MF, the SIM shall assume that the ML does not support 
SIM Application Toolkit. 



5.2 Structure and coding of TERMINAL PROFILE 

Direction: ML to SIM 

'The command header is specified in GSM I LI i |20]. 
Command parameters/data: 



Description 


Section 


M/O 


Length 


Profile 




M 


Igth 



Profile: 

Contents:' 'The list of SIM Application Toolkit facilities that are supported by the ML. 
Coding: 

I bit is used to code each facility: 
bit = l : facility supported by ML 
bit = 0: facility not supported by MH 

First, byte (Download): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



Profile download " 

SMS-PP data download 

Cell Broadcast data download 

Menu selection 

' 9 EXX ' response code for SIM data download error 
Timer expiration 

USSD string data object supported in Call Control 
Envelope Call Control always sent to the SIM during 
automatic redial mode 
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Second byte (Other): 



b8 


bl 


be 


bS 


b4 


b3 


b2 


bl 



Command result 
[Call Control by SIM 

"cell identity included in Call Control by SIM 
MO short message control by SIM 
Handling of the alpha identifier according to 
subclause 9.1.3 
UCS2 Entry supported 
UCS2 Display supported 
Display of the extension text 



Third byte (Proactive SIM): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



Proactive 
Proactive 
Proactive 
Proactive 
Proactive 
Proactive 
Proactive 
Proactive 



SIM: 
SIM: 
SIM: 
SIM: 
SIM: 
SIM: 
SIM: 
SIM: 



DISPLAY TEXT 
GET INKEY 
GET INPUT 
MORE TIME 
PLAY TONE 
POLL INTERVAL 
POLLING OFF 
REFRESH 



Fourth byte (Proactive SIM): 



b8 


bl 


b6 


b5 


b4 


b3 


b2 


bl 



Proactive SIM: 
^Proactive SIM: 
"proactive SIM: SEND SS 
"proactive SIM: SEND USSD 

Proactive SIM 
"proactive SIM 



SELECT ITEM 
SEND SHORT MESSAGE 



SET UP CALL 
SET UP MENU 

Proactive SIM: PROVIDE LOCAL INFORMATION (MCC, MNC , 
LAC, Cell ID Sc IMEI) 
"Proactive SIM: PROVIDE LOCAL INFORMATION (NMR) 



Filth byte (Event driven information): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



Proactive SIM: SET UP EVENT LIST 



Event 
Event 
Event 
Event 
Event 
Event 
Event 



MT call 

Call connected 

Call disconnected 

Location status 

User activity 

Idle screen available 

Card reader status 



Sixth byte (Event driven information extensions): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



Event 
Event 
Event 
Event 
RFU, bit 



Language selection 
Browser Termination 
Data available 
Channel status 



Seventh byte (Multiple card proactive commands) for class "a" 



b8 


bl 


b6 


b5 


b4 


b3 


b2 


bl 



Proactive SIM: POWER ON CARD 

Proactive SIM : POWER OFF CARD 
"proactive SIM : PERFORM CARD APDU 
"Proactive SIM: GET READER STATUS (Card reader 

status) 

"proactive SIM: GET READER STATUS (Card reader 

identifier) 
"RFU, bit = 0 
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Umhlh byle (Proactive SIM): 



Proactive SIM: TTMKK MANAGEMENT {.>.;!: an. , stop) 
Proactive S T M : TIMER MANAGEMENT (get current value)- 
Proactive SIM: PROVIDE LOCAL INFORMATION (Urft«-- ( 

time and time -/one) 
Binary choice in GET IN KEY 

RUN AT COMMAND {i.e. class "b" is supported) 

2nd alpha identifier in SET UP CALL 

2nd capability configuration parameter (see 'J. 1.6) 



Ninth byte: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



Sustained DISPLAY TEXT {see 6.4.1) 
SEND DTMF command (nee 6:4.24) 

Proactive SIM: PROVIDE LOCAL INFORMATION - liCOH 

Channel List coding as.. in subclause 12.2'J) 
Proactive StM: PROVIDE LOCAL INFORMATION ( language) 
Proactive SIM: PROVIDE LOCAL INFORMATION (Timing 
Advance) 

P r oa c c i ve SIM : LANGl J AGE NOT I FT. CAT I ON 
Proactive SIM: LAUNCH BROWSER 
RFU, bit - 0 



Tenth byte (Soft keys support): 



b3 


b7 


b6 


,s 


b4 


b3 


b2 


bl. 



Klcvcnlh byte (Soft keys information): 



Soft keys supporr ror SELECT LTEM (see ( > . 

Soft Keys support for SET UP MENU (nee G. 

RFU, bit •- 0 

RFU , bit 0 

RFU, bit = 0 
RFU, 



. 9) 
. 3) 



RFU, 
RFU, 



bit - 0 
bit - 0 



b8 


b7 


b6 


b5 


b4 


b 




b2 























Maximum number of aoft keys available 
' FF ' value is reserved Lor future use 



Twelfth byle (Bearer Independent protocol proactive commands (class V): 



b8 



bl 



h6 



bS 



b4 



b3 



b2 



Proactive SIM: OPEN CHANNEL 
"Proactive SIM : CLOSE CHANNEL 
^Proactive SIM: RECEIVE DATA 
_ Proactive SIM : SEND DATA 
"Proactive SIM: GET CHANNEL STATUS 
_ RFU , blL « 0 

RFU, bit 0 " '. 

RFU, bit = 0 • ' 



Thirteenth byle (Bearer Independent protocol supported bearers (class V)): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



CSD supported by ME 

GPRS supported by ME 
_ RFU, bit - 0 
"RFU, bit =0 
"RFU, bit = 0 

"Number of channels supported by ME 
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Fourteenth byte (Screen height): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



Fifteenth byte (Screen width): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



Sixteenth byte (Screen effects): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



Number of characters supported down the ME display 
as defined in 5.3.1 
RFU, bit = 0 

Screen Sizing Parameters supported as defined in 
section 5.3 



Number of characters supported across the ME 
display as defined in 5.3.2 
Variable size fonts Supported 



Display can be resized as defined in 5.3.3 
Text Wrapping supported as defined in 5.3.4 
Text Scrolling supported as defined in 5.3.5 
RFU 
RFU 

Width reduction when in a menu as defined in 5.3.6 



Seventeenth byte: (Bearer independent protocol supported transport interface) for class "e": 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 





















Subsequent bytes: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 



T 



I I I I I 



TCP 
UDP 

RFU, bit = 0 



RFU, bit = 0 



RFU bits, and all bits of subsequent bytes, are reserved to indicate future facilities. A SIM supporting only the 
features of SIM Application Toolkit defined here shall not check the value of RFU bits. 

Response parameters/data: None. 

5.3 Definition of display parameters in Profile download 

This subclause defines the terms used for defining the passing of the ME's screen parameters from the ME to the SIM. 

5.3.1 Number of characters supported down the ME display 

This is the guaranteed number of characters supported down the ME display without scrolling (using the default 
character set specified in GSM 03.38 1 51) as a result of a Display Text Proactive command. 

If the screen resized as defined in 5.3.3 then this value shall be the initial number of characters supported before the 
display can be resized. 

5.3.2 Number of characters supported across the ME display 

This is the guaranteed number of characters supported across the ME display without scrolling (using the default 
character set specified in GSM 03.38 151) as a result of a Display Text Proactive command that can be viewed in one 
instance. 

If the screen resized as defined in 5.3.3 then this value shall be the initial number of characters supported before the 
display can be resized. 
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5.3.3 Display can be resized 

Display can be resized is . supported if either: ... 

- The user can change ihc number of characters supported across the display, down the display or both. 

- - The MH can dynamically change ihe number of characters supported across ihe display, down the display or 

both. 

5.3.4 Text Wrapping 

Text wrapping is supported if the ML: puis words that would be split across two lines, due to the display size, at the 
beginning of ihc next line down. 

5.3.5 Text Scrolling 

U-m scrolling is supported if the MF. scrolls, on one line, words that would be split across two lines, due to ihe display 

5.3.6 Width reduction when in a menu 

; |„, value is the number of characters available across the display due to a DISPLAY TEXT proactive command 
.v ,.i„mt serollino (using the default character sel specified in GSM 03.38 [5|) minus the number of characters available 
.k i^s the display due to a SELECT ITEM proactive command without scrolling (using the default character set 
tiled in GSM 03.3 H 151). 

i; ;| K . scrcen resized as defined in 5.3.3 then this value shall be calculated using die initial number of characters 
supported before the display can be resi/.ed. 



6 Proactive SIM 
6.1 Introduction 

( iSM I l . I I |2()| defines thai the ME communicates to the SIM using the T=0 protocol, which is specified in 
ISO/IFC 78 1 6-3 [1 6]. The ME is always the "master" and initiates commands to the SIM, and therefore there is no 
mechanism lor the SIM to initiate a communication with the MP.. This limits the possibility. of introducing new SIM 
features requiring the support of the ME, as the MR needs to know in advance what actions it should take, 

The SIM shall execute all SIM Application Toolkit Proactive commands or procedures in such a way as not to 
jeopardise, or cause suspension, of service provisioning to the user. This could occur if. for example, execution of the 
RUN GSM ALGORITHM is delayed by internal SIM Toolkit activity, which would result in the network denying or 
suspending service to the user. Specifically, the MORE TIME command shall be used, whenever possible, to allow the 
Ml-! access to the GSM functionality of the SIM if Toolkit applications take an unreasonable time .to complete execution. 

• Note: The maximum delay before the sending of a MORli TIME command is required depends on several 

factors (e.g. the permissible duration of a nclwork-SIM authentication); in some cases a maximal delay of 
2 seconds could be required. During this period the NULL procedure byte operation shall be respected as 
defined in GSM I I.I I '[20]. 

The proactive SIM service provides a mechanism which stays within me protocol of T=0, buL adds a new status response 
word SW I . This status response has the same meaning as the normal ending ('90 ()()'), and can be used with most of the 
commands that allow the normal ending, but it also allows the SIM to say to the ME "I have.some information to send to 
you". The ME then uses the FETCH function to find out what this information is. 

To avoid cross-phase compatibility problems, these functions shall only be used between a proactive SIM and an ME 
that supports the proactive SIM feature. 

The SIM can issue a variety of commands through this mechanism, given in alphabetical order: 
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- CLOSE CHANNEL, which requests the ME to close the specified data channel (if class V is supported). 

- DISPLAY TEXT, which displays text or an icon on screen. A high priority is available, to replace anything else 
on screen. 

- GET CHANNEL STATUS, which requests the ME to return the current status of all available data channcl(s) 
(if class V is supported). 

- GET INKEY, which sends text or an icon to the display and requests a single character response in return. It is 
intended to allow a dialogue between the SIM and the user, particularly for selecting an option from a menu. 

- GET INPUT, which sends text or an icon to the display and requests a response in return. It is intended to allow 
a dialogue between the SIM and the user. 

- GET READER STATUS, which gives information about the additional reader(s) and inserted card(s) (Card x 
state, e.g. powered on or not, Card x Presence), if class "a" is supported. 

- LANGUAGE NOTIFICATION, which allows the SIM to notify the ME about the currently used language in 
text strings issued by the SIM Application Toolkit application. 

- LAUNCH BROWSER, which requests a browser inside a browser enabled ME to interpret the content 

corresponding to a URL. 

- MORE TIME, which docs not request any action from the ME. The ME is required to respond with 
TERMINAL RESPONSE (OK) as normal - see below. The purpose of the MORE TIME command is to provide 
a mechanism for the SIM Application Toolkit task in the SIM to request more processing time. 

- OPEN CHANNEL, which requests the ME to open a data channel with parameters indicated in the command (if 
class "c" is supported.) 

- PERFORM CARD APDU, which requests Lhe ME to send an APDU command to the additional card, if class 
"a" is supported. This command is compatible with any protocol between the ME and the additional card. 

- PLAY TONE, which requests the ME to play a tone in its earpiece, ringer, or other appropriate loudspeaker. 

- POLL INTERVAL, which negotiates how often the ME sends STATUS commands to the SIM during idle 
mode. Polling is disabled with POLLING OFF. Use of STATUS for the proactive SIM is described in 
GSM ll. 11 [20]. 

- POWER OFF CARD, which closes the session with the additional card, if class "a" is supported. 

- POWER ON CARD, which initiates a session with the additional card and returns all the ATR bytes, if class "a" 
is supported. 

- PROVIDE LOCAL INFORMATION which requests the ME to pass local information to the SIM, for 
example the mobile country and network codes (MCC + MNC) of the network on which the user is registered. 

- RECEIVE DATA, which requests the ME to return to the SIM data received on the specified channel (if class 
V is supported). 

- REFRESH, which requests the ME to carry out a SIM initialization according to GSM 11.11 subclause 1 2.2. 1 , 
and/or advises the ME that the contents or structure of EFs on the SIM have been changed. The command also 
makes it possible to restart a card session by resetting the SIM. 

- RUN AT COMMAND, which will convey an AT Command to the ME, and cause the response to the AT 
Command to be returned to the SIM. 

- SELECT ITEM, where the SIM supplies a list of items, and the user is expected to choose one. The ME 
presents the list in an implementation-dependent way. 

- SEND DATA, which requests the ME to send on the specified channel data provided by the SIM (if class "e" is 
supported). 

- SEND DTMF, which requests the ME to send DTMF tone(s) during an established call. 
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SEND SHORT MESSAGE, which sends a short message or SMS-COMMAND lo the network. 

- SEND. SS. which sends an SS request lo the network. ^ 

- SEND USSD ? which sends a USSD string to the network. 

- SET UP CALL, of which there are three types: 

- set up a call, but only if not currently busy on another call: 

- set up a call, putting all other calls (if any) on hold: 
■ set. up a call, disconnecting all other. calls (if any): 

' SET UP EVENT LIST where the SIM supplies a list of events which it wants the ML to provide details of when 
these events happen. 

- SET UP IDLE MODE TEXT, which supplies a text siring to'be used by the ML as stand-by mode text. 

SET UP MENU, where the SIM supplies a list of items to be incorporated into the MH's menu structure. 

TIMER MANAGEMENT, which requests the ML to manage a timer in a way described in the command (start, 
deactivate and get the current value) and, in the case of starting a timer, for a duration indicated in the command. 

The ML tells the SIM if the command was successful or not using the command result procedure defined in subclause 
6.7. Responsibility for what happens after that (whether lo repeat the command, try another one immediately, try again 
sometime later, or not to try again at all) lies with the SIM application. However, the SIM application needs to know- 
why the command failed, so the ML provides the SIM with the result of the command. 

Results are grouped into three main types: 

- OK. 

- Temporary problem. These results are further broken down into types of temporary problems, and specific 
causes. Generally, they indicate to the SIM that it may be worth trying again. 

- Permanent problem. These results are again further broken down into types of permanent problems, and specific 
causes. Generally, they indicate lo the SIM that it is not worth trying again during this GSM session. 

If the SIM issues an instruction to the ML to initiate a Mobile Originated transaction (e.g. SLND SMS, SKND USSD or 
SLND DTMF). then unless explicitly stated elsewhere in the present document or in GSM 11.11 1 14|, the content 
supplied hy the SIM for onward transmission by the MR shall not be altered by the ML. 

6.2 Identification of proactive SIMs and of ME support 

A proactive SIM shall be identified by having the proactive SIM service activated in the SIM Service Table (see 
GSM 11.11 [20]). An ML that supports proactive SIMs shall be identified as such when it sends a TERMINAL 
PROL1LL command during SIM initialization. The ML shall then send STATUS commands to the SIM at intervals 
determined by the poll interval procedure (see subclause 6.4.6). 

A proactive SIM shall not send any command requests (status bytes SW 1 SW2 = '9 1 XX') to a mobile that does not 
support the proactive SIM feature. . 

An ML lhat supports the proactive SIM feature shall not send proactive SIM related commands lo a SIM that does not 
have the proactive SIM service activated. 

6.3 General procedure • 

For all of the procedures that can end in '90 00' (indicating normal ending to the command), and which cannot end in '9P 
' XX'Vcsponse data available from SIM), a proactive SIM operating with an ML that supports proactive SIMs may 
instead use the status response '91 XX. tm . 

The response code '9 1 XX' shall indicate Lo the ML that the previous command has been successfully executed by the 
SIM in the same way as '90 00* (i.e.. "OK"), but additionally it shall indicate response data which contains a command 
from the SIM for a particular ME procedure (defined in subclause 6.4). 
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The value 'XX' indicates the length of the response data. The ME shall use the FETCH command to obtain this data. 

It is the responsibility of the SIM to remind the ME of a pending proactive command by applying the '9 1 XX' returncode 
until it is fetched by the ME. 

Note: The last value of 'XX' received in a '91. XX' returncode from the SIM should be used by the ME in a 
following FETCH command. 

It is recommended that the ME interprets a '90 00' following a '9 1 XX' without a corresponding FETCH as 
if no proactive command is available in the SIM and regard the proactive SIM session as being 
terminated. However, the SIM should be able to handle a FETCH command being sent in this case, e.g. by 
applying the appropriate error handling (cf. "Handling of unknown, unforeseen and erroneous messages"). 

GSM 11.11 [20] shows how the SIM can initiate a proactive command in each of the five cases of transmission protocol 
identified in GSM 11.11 [20|. Some commands require the SIM to indicate that it has response data for the ME (through 
SW1/SW2 = '9F XX'), and the ME gets this data using the .GET RESPONSE command. 

When the ME has received a command from the SIM, it shall attempt to process the command immediately. 

- If the command has been successfully executed, the ME shall inform the SIM as soon as possible, using 
TERMINAL RESPONSE. 

- If the command was not successfully executed, the ME shall inform the SIM as soon as possible using 
TERMINAL RESPONSE with an error condition. 

Responsibility for re-trying lies with the SIM application. The SIM application can make a judgement whether to send 
the same command again, to send a different one, or not to try again, from the information given by the ME in 
TERMINAL RESPONSE. If the SIM application wishes the ME to try again, it shall issue a new (identical) command. 

Only one proactive command can be ongoing at any one time. 

6.4 Proactive SIM commands and procedures 

6.4.1 DISPLAY TEXT ;; 

This command instructs the ME to display a text message, and/or an icon (see 6.5.4). It allows the SIM to define the 
priority of that message, and the text string format. 

Two types of priority are defined: 

- display normal priority text and/or icon on screen; 

- display high priority text and/or icon on screen. 

The text string can be in one of three formats: 

- packed format in SMS default alphabet - (see 12. 15.2); 

- unpacked format in SMS default alphabet - (see 12. 15.2); 

- UCS2 alphabet format - (see 1 2. 153). 

Note: From release 98 onwards the text string may contain up to 240 bytes. 

A flag (see command qualifier, subclause 12.6) shall be set to inform the ME whether the availability of the screen for 
subsequent information display after its use for 'Display Text' should be either after a short delay (the duration of the 
delay being at the discretion of the ME manufacturer), or following a user MMI action. 

An immediate response object may be included by the SIM, to indicate if the ME should sustain the display beyond 
sending the TERMINAL RESPONSE. ME support of this feature is indicated in the PROFILE DOWNLOAD. The 
behaviour of non-supporting MEs is dependent on the Comprehension Required flag. 

- If the user has indicated the need to end the proactive SIM application session, the ME shall send a TERMINAL 
RESPONSE with "Proactive SIM application session terminated by the user" result value. 
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- If lh c user has indicated the need lo go backwards in the proactive SIM application session, the MB shall send a 
TERMINAL- RESPONSE with "Backward'move in theproactive SIM session requested by the user result 
value. 

.. „■ a , 1a „ 0 f lhc command qualifier (see subclause 12.6) indica.es thai the Ml: shall wait for the aseruv clear 
„' essli and if the Mli decides thai m, user response has been rccctved, the ME shall send a LUMINAL 
RESPONSE wilh "No response from user" result value. 

U-.hc SIM ineludesan immediate response object, the MF. shall immediately send TERMINAL RESPONSE 
.Command performed successfully). The ME shal.continuc to display the text unul one of the following events 



occurs: 



a subsequent proactive command is received containing display data: 

- ' ihe expiration of the short delay, if so indicated by the command cjualiher; 

- fol lowing a user MM I action; 

. when a higher priority event occurs, e.g. an incoming mobile terminated call. 

No further TERMINAL RESPONSE shall be sent when the ME removes the text from the display, regardless of 
die cause. 

. . ( Xhcrw.sc. the MH shall send TERM IN AI . RESPONSE (Command performed successfully ) at the expiration of 

ihe short delay, or following a user MM I action not described above: 
In each case the availability of the screen lor- the subsequent information display is defined in subclause 6.9. 

NO I L 2: Lor the case where the text is cleared after a short delay. Ihe ME may also allow the user to clear the 
display via the MM1 prior to this. 
The ML shall reject normal priority text commands if the screen is currently being used lor more than its normal sland- 
l display i. ie command is rejected, the ME informs the S.M using TERMINAL RESPONSE (ME currently unable 
to process command - screen busy). 

H,,h priority text shall be displaved on the screen immediately, except if there is a conflict of priority level of alerting 
ifo h p. .only lex s | ^ w . (rnin „ , n lha( siiuation, the resolution is left to the ML. II the command is 

^"^t hlgC^y I ME shall inform the SIM using TERMINAL RESPONSE (ME currently unahle 
lo process command - screen is busy). 

U help information is requested by the user, this command may be used to display help information on the screen. The 
^ll^L should be sent as high priority text and with the option that it should be cleared alter a short delay. 

6.4.2 GET INKEY 

This command instructs the ME to display text and/or an icon (see 6.5.4) and to expect the user to enter a single 
character. Any response entered by the user shall be passed transparently by the ME to the SIM. 

The text can be in one of three formats: 

- packed format in SMS default alphabet - (see 12. 15.2); 

- unpacked formal in SMS default alphabet - (see. 12.15.2): 
UCS2 alphabet format - (see 12. 15.3). 

' The response can be from one of three character sets. This is specified by the SIM: 

- digits only (0-9, *,#, and +): m . , * . : .. ■. 

- characters from, the SMS default alphabet: . . *. • ■ . . . 

- characters from the 0CS2 alphabet. 

.Upon receiving the command, the ME shall display the text. The ME shall allow the user to enter a single character in 
response. _ , . ■ * . 

If the user has indicated the need to go backwards in the proactive SIM session, the ME shall send a TERMINAL 
• ' ' RESPONSE with "Backward move in the proactive SIM session requested by the user result value. 

If the user has indicated the need to end the proactive SIM session, the ME shall send a TERMINAL 
RESPONSE with "Proactive SIM session terminated by the user" result value. 
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- If the ME decides thai no user response has been received, the ME shall send a TERMINAL RESPONSE with 
"No response from user" result value. 

- If the SIM requests a digit only, the ME shall only allow the user to enter a character from the digits 0-9 ? *, # and 
+. When the user has entered a digit, the ME shall pass the entered digit transparently to the SIM, using 
TERMINAL RESPONSE. 

- If help information is available for the command and if the user has indicated the need to get help information, 
the ME shall send a TERMINAL RESPONSE with "help information required by the user" result value. 

- If the SIM requests a character from the SMS default alphabet, the ME shall allow the user to enter a character 
using characters from this alphabet. When the user has entered a character, the ME shall pass the entered 
character transparently to the SIM, using TERMINAL RESPONSE. 

- If the SIM requests a "Yes/No" response, the ME shall allow the user to enter either a positive or a negative 
decision using MMI means left to ME manufacturer's choice (keypad, touch screen, softkey,...). The ME may use 
SEND, ACCEPT or END functions in relation to GET INKEY "Yes/No" response. If used, the SEND and 
ACCEPT functions as defined in GSM 02.30 [4] shall mean positive decision and the END function as defined in 

. GSM 02.30 [4] shall mean a negative one. Depending on the user's choice, the ME shall pass the positive or a 
negative value to the SIM, using TERMINAL RESPONSE. 

NOTE: If the MMI of the ME requires more than one keypress in order to select a character, it is an 

implementation decision for the ME manufacturer how to indicate completion (e.g. timeout, pressing 
SEND, OK). It may be useful to echo the input character on the display. 

For digits only (0-9,*,# and +) and SMS default alphabet characters sets, the response shall be coded using the SMS 
default alphabet in unpacked format. 

6.4.3 GET INPUT 

This command instructs the ME to display text and/or an icon (see 6.5.4) and that any response string entered by the 
user shall be passed transparently by the ME to the SIM and shall not be stored in the ME. If the SIM provides a default 
text, the ME shall display this default text, which the user may accept, reject or edit as the response string. 

The text can be in one of three formats: \ 

- packed format in SMS default alphabet (see 1 2. 1 5.2); 

- unpacked format in SMS default alphabet (see 1 2. 1 5.2); 

- UCS2 alphabet format (see 12. 15.3). 

The SIM indicates how many characters are expected for the response string, by giving a minimum and a maximum 
acceptable length. 

The SIM specifies three variables lor the response string it is expecting from the user: 

- the response contains either digits only (0-9, *, # and +) or characters from the SMS default alphabet; 

- the response for digits only (0-9,*,# and +) or characters from SMS default alphabet is either in an unpacked 
format or in a packed format; 

- the ME may display the text string being entered by the user (the response), or the ME shall hide (i.e. not 
display) the actual text string. 

The combination of characters from the SMS default alphabet and hidden entry mode is not allowed. In hidden entry 
mode, only digits from the set "0-9", and "#" are allowed for the user input. 'V is not allowed for user input in this 
mode. 

If the SIM requests that the user input (text string) is to be hidden, it is permissible for the ME to indicate the entry of 
characters, so long as the characters themselves are not revealed. 

Upon receiving the command, the ME shall display the text. The ME shall allow the user to enter characters in response. 

- The ME MMI is responsible for managing the entry of the correct number of characters. 
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,f ,hc user has indicated .he need to go backwards in the proactive SIM sess,ot, the Mb shall send a TKRMINAI . 
" RESKWSL with "Backward move in the proactive SIM session requested by .he user result value. 

. li the user has indicated the need U>c„d the proactive SIM session, the Mb shall send a TP.RMINAI. 

RESPONSE with "Proactive SIM session terminated by the user result value. 
. ir lh e Mb decides .ha. no user response has been received, .he ME shall send a TERMINAL RESPONSE with 

"No response from user" result value. 

,f the SIM requests dibits only, the Mb shall only allow the user to enter the digU s (W. M » and , ™ 
11 indicated completion! the MH shall pass the entered dig,, string .ransparent.y to the SIM. us.ng bKMINAL 
RESPONSE. 

If. he SIM requests characters Iron, .he WCS2 alphabet or SMS default alphabet, the Mb shall allow the user to 

a ha cter trulg using characters Iron, one of these alphabets. ^ 
Mb shall pass the entered text string transparently to the SIM, usmg I ERMINAb RESPONSE. 

. if help information is available for the command and if the user has indicated the ^fj^^^^ 
the Mb shall send a TERMINAL RESPONSE with 'help inlorma.um required by the use, ttsull value. 

If ,he SIM requests the user input to be in packed format, then the ME shall pack the text according to GSM 03.38 |5| 
before submitting il 10 the SIM. . 

644 MORE TIME 

place in the background. 

The Mb shall take no extraordinary action when i, receives this command, and all other operations shall be ^dcae'I 
\t Mb shall delude the command by sending TKRMINAI. RESPONSE (OK) to the SIM. as soon as poss.ble a.tct 
receiving the MORE TIME command. 

6.4.5 PLAY TONE 

Phis command instructs the Mb to play an audio tone. 

Upon receiving this command, the ME shall cheek if i, is currently in. or in the process of setting up (SET-UP message 
sent to the network, see GSM 04.08 1X1). a speech call. 

' if ,he MF is in or is settins up a speech call, il shall superimpose the tone on top of the downlink audio (if any). 
: b the durat ion" in in the com, nand. The progress or current state of the call shall no, be affected m any way. 
H e ML S c^d the TERMINAL RESPONSE (Command performed successfully) as soon as poss.ble alter 
'he ,2 has been completed and. if an alpha identifier was included and delayed, the screen ts avmlable to, 
subsequent information display. 

. lf the ME is no. in or setting up a speech call, it shall route the audio ^^^^^ 
audio device and play the tone for the duration given m lhe command. The MF. shall send the 1 LKMIINA, 
R™SF ( <n, mand performed successfully) as soon as possible after the tone has been completed and, tf an 
a.pha ident.fier was included and displayed, the screen is available for subsequent tn.ormat.on d.sp.ay. 

If the user has indicated the need to end the proactive SIM application session while the ME plays the tone, the 
' ME shaH slop playing the tone and shall send a TERMINAL RESPONSE with "Proacuvc SIM apphcauon 
session terminated by lhe user" result value. 

data object and/or an icon (see 6.5.4). 
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If ihe ME is required to generate a supervisory tone due to the progress of the current call (e.g. the network sends the 
ME call control cause information) as defined in GSM 02.40 f 18], then the call supervisory tone shall take precedence 
over the tone requested by the SIM. 

6.4.6 POLL INTERVAL 

This procedure negotiates how often the ME shall send STATUS commands related to Proactive Polling (defined in 
GSM 1 1.1 1 120J). The SIM indicates the poll interval it requests from then onwards, and the ME responds through 
TERMINAL RESPONSE with the maximum interval that it will use. If the ME does not support the poll interval 
requested by the SIM, then the ME shall respond with the closest interval to the one requested by the SIM, or, if the 
intervals the ME can offer are equidistant (higher and lower) from the SIM's request, the ME shall respond with the 
lower interval of the two. 

Applications on the SIM should not request short time intervals for an extended period, as this will have an adverse 
effect on battery life. 

6.4.7 REFRESH 

The purpose of this command is to enable the ME to be notified of the changes to the SIM configuration that have 
occurred as the result of a SIM application activity. It is up to the SIM application to ensure that this is done correctly. 

The command supports five different modes: 

- SIM Initialization. This mode tells the ME to carry out SIM initialization as it is defined in GSM 11.11 subclause 
1 1.6.1 only, starting after the CHV1 verification procedure. The ME shall not reset the SIM electrically. 

- File Change Notification. This mode advises the ME of the identity of the EFs that have been changed (in 
structure and/or contents) in the SIM. This information can be used by the ME if there is an image of SIM EFs 
(e.g. the ADN file) in the ME's memory, to determine whether it needs to update this image. 

- SIM Initialization and File Change Notification. This is a combination of the first two modes above. 

- SIM Initialization and Full File Change Notification. This mode causes the ME to perform the SIM initialization 
procedure of the first mode above and advises the ME that several EFs have been changed (in structure or 
contents) in the SIM. If there is an image of SIM EFs in the ME's memory, the ME shall completely update this 
image. 

- SIM Reset. This mode causes the ME to run the GSM session termination procedure and to deactivate the SIM in 
accordance with GSM 11.11 (20]. Subsequently, the ME activates the SIM again and starts a new card session. In 
case of a 3 Volt technology ME, the ME shall restart the SIM with the same supply voltage as in the previous 
session, if the ME can ensure that the SIM has not been changed in between. Otherwise, the ME shall perform the 
supply voltage switching.in accordance with GSM 1 1 . 1 2 [2 1 J. The ME shall not send the TERMINAL 
RESPONSE; this is an exception from the normal procedure, where TERMINAL RESPONSE is sent after 
completion of the command. The SIM Application shall interpret a new activation of the contacts of the SIM as 
an implicit TERMINAL RESPONSE. The SIM Reset mode is used when a SIM application requires ATR or 
complete SIM initialization procedures to be performed. SIM Applications should take into account that early 
implementations of SIM Application Toolkit in some MEs may send a TERMINAL RESPONSE after 
performing the REFRESH command involving resetting the.SIM electrically. - - 

If the ME performs the REFRESH command successfully for only those EFs indicated in the mode, the ME shall inform 
the SIM using TERMINAL RESPONSE (OK), after it has completed its refreshing. 

For REFRESH commands with mode other than "SIM Reset", it is permissible for the ME, as part of its execution of the 
REFRESH command, to read EFs in addition to those notified by the SIM, or to perform a SIM initialisation, provided 
that the procedure executed wholly encompasses the mode requested by the SIM. The ME shall not electrically reset the 
SIM. If the ME does the refreshing successfully, it shall inform the SIM using TERMINAL RESPONSE (Refresh 
performed with additional EFs read), after the ME has completed its refreshing. It should be noted that reading 
additional EFs will lengthen the refresh procedure. • • 
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If die MF receives a RFl-RFSH command while in a stale where execution ol' the command would he unacceptable. 
llZilZZ user operation (e.g. notification during a cull that the IMS. has changed, the ML shah m.orn, the 
SIM usin- TFRMINAL RFSI'ONSF (Mli currently unable to process command - currently busy on call) or 
TLKMINAI, RFSI'ONSF (Ml- currently unable to process command - screen is busy) as appropriate. 

NOTF- Man* MHs copy an image of the SIMs memory to die MF. at initialization to speed up access to these 

Heidi during a GSM session. One of the purposes of this coding of the RFFRFSH command ,s to enable 
MB U> change such an image efficiently. 

„■ on rece.pt of the RLFRFSH command, the MF. repl.es that it is busy (e.g. in call or navigating menus), the toolkit 
applLation may shorten the polling interval utilising the POI .1 . INTERVAL command in order to. resend the RI.PRFSH 
command more frequently. 

- „ is recommended for the Mi: to minmuse the use of sending temporary problem TERMINAL RLSPONSF as during 
the period between the SIM issuing a RFFRFSH command and the MF performing the re.resh procedure, there may be 
Insistencies between data held in the ML and in the SIM. However, responsibility lor retrying or all pro-act.ve 
commands lies with the SIM Application. 

6.4.7.1 EFimsi changing procedure 

When L1-.MS, is changed via Data Download or a.SIM Toolki, application and a RFFRFSH command is issued by the 
SIM the following rules apply to the SIM Toolkit and MF: 

- SIM Initialization. Th.s command shall not be used , f KF 1MSI is changed, as the behaviour of the MS is 
unpredictable. 

- File Change Notification. This command shall not be used il FF WS1 is changed, as the behaviour of the MS is 
unpredictable. 

- SIM initialization and File Change Notification. If LF, MS , is pan of the file change notification, the ML shall 
invoke the MM Restart procedure defined in 03.22 |28|. 

- S TM Initialization and l ull bile Change Notification. The ML shall invoke (he MM Restart procedure defined in 
03.22 [28]. 

- SIM Reset. Normal SIM Reset procedure is carried out. 

ir LF'imsi is 10 be updated, neither FF» 1S1 nor UF,,„ , shall be updated in the SIM before the phase request procedure has 
been executed by the MF. 

6.4.8 SET UP MENU 

The SIM shall supply a set of menu items, which shall be integrated with the menu system (or other MM1 facility ) in 
order to .five the user the opportunity to choose one of these menu items at his own discretion. Lach item comprises a 
shon [identifier (used to indicate the selection), a text string and optionally an icon idcnlil.cr. contained ,n an item icon 
identifier list data object located at the end of the list ol items. 

The SIM shall include an alpha identifier, and optionally an icon identifier, which acts as a title for the list of menu 
items. This icon may be used by the ML to provide an entry into the list of toolki. menu items for the user. 

If an icon is provided by the SIM, the ieon(s) indicated in the command may be used by the ME in .addition to, or 

stead of the alpha identifier or text siring, as indicated with the icon qualifier (see subclause 6.5.4). Addmonally , 
X lni » .nd.ca.ed in the command details and soft key for SFT UP MLNU .s supported by the MF and he 
number of icon items does not exceed the number of soft keys available, then the MF shall display those icons as solt 
key. . 
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The SIM may include an items next action indicator data object located at the end of the list of items. The inclusion of 
the items next action indicator is to allow the ME to indicate to the user the consequences of performing the selection of 
an item. 

NOTE: The maximum amount of data sent in one proactive SIM command is 256 bytes. It is therefore 

unavoidable that there is trade-off between the number of items and the length of the descriptive text (the 
alpha identifier of the SET-UP MENU command and the text strings of the items), e.g. for an average 
length of 10 bytes per text string the maximum amount of items is 1 8. 

The list of menu items shall then be part of the menu system of the ME and the user is allowed to select an item from 
this list. The presentation style is left as an implementation decision to the ME manufacturer. However, the ME shall 
present the menu items in the order given by the SIM, unless instructed otherwise by the user, or when this would be 
inappropriate for the presentation style of the ME. The menu provided by the SIM in the last SET UP MENU command 
shall no longer be part of the menu system of the ME if the ME is powered off or the SIM is removed or electrically 
reset, 

Any subsequent SET-UP MENU command replaces the current list of menu items supplied in the previous SET-UP 
MENU command. The SET-UP MENU command can also be used to remove a menu from the menu system in the ME; 
see subclause 6.6.7. 

When the ME has successfully integrated or removed the list of menu items, it shall send TERMINAL RESPONSE 
♦ OK) to the SIM. 

When the ME is not able to successfully integrate or remove the list of menu items, it shall sent TERMINAL 
RESPONSE (Command beyond ME's capabilities). 

When the user has selected one of the menu items of this menu item list, then the ME shall use the Menu Selection 
mechanism to transfer the identifier of the selected menu item to the SIM. 

II help is available for the command and if the user has indicated the need to get help information on one of the menu 
items, the ME shall use the Menu Selection mechanism to inform the SIM about this help request. 

6.4.9 SELECT ITEM 

The SIM shall supply a set of items from which the user may choose one. Each item comprises a short identifier (used to 
indicate the selection), a text string and optionally an icon identifier, contained in an item icon identifier list data object 
located at the end of the list of items. 

Optionally the SIM may include an alpha identifier, and an icon identifier. These arc intended to act as a title for the list 
of items. The SIM may include an items next action indicator data object located at the end of the list of items. The 
inclusion of the items next action indicator is to allow the ME to indicate to the user the consequences of performing the 
selection of an item. 

The alpha identifier included by the SIM shall be used by the ME as the title for the list of items. 

If an icon is provided by the SIM, the icon(s) indicated in the command may be used by the ME in addition to, or 
instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4). Additionally, if "selection using 
soft key preferred" is indicated in the command details and "soft key for SELECT ITEM" is supported by the ME and 
the number of icons items does not exceed the number of soft keys available, then the ME shall display those icons as 
soft keys. 

NOTE: The maximum amount of data sent in one proactive SIM command is 256 bytes. It is therefore 

unavoidable that there is trade-off between the number of items and the length of the descriptive text (the 
alpha identifier of the SELECT ITEM command and the text strings of the items), e.g. for an average 
length of I0 bytes per text string the maximum amount of items is 1 8. 

The ME shall present the list of text strings to the user, and allow the user to select an item from this list. A flag of the 
command qualifier (see subclause 1 2.6) indicates whether the list is a choice of navigation options, or a choice of data 
values. The presentation style is left as an implementation decision to the ME manufacturer. However, the ME shall 
present the menu items in the order given by the SIM, unless instructed otherwise by the user, or when this would be 
inappropriate for the presentation style of the ME. 

The SIM may supply with the list, if applicable, indication of the default item, e.g. the previously selected item. 
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When the user has selected an num. the ML shall send TURMINAI , RKSPONSL (OK) to the SIM with the idemifier of 
the ileni chosen. 

If, hc user has indicated die need lo end ihc proactive SIM scssiu,,. the MK shall send u TERMINAL 
' RHSPONSK with "Proactive SIM session terminated by ihc user" result value. 

If the user has indicated the need to go backwards it, the proactive SIM session, the ML shall send a TERMINAL 
■ RFSPONSF.-with "Backward move in the proactive SIM session requested by the user" result value. 

■ ,, the MH decides that no user response has been received, the ML shall send a TERMINAL RESPONSE with 
"No response from user" result value. 
- If help information is available lor the command and if the user has indicated the need to get help inloniuilion, 
ihc ML shall send a TERMINAL RFSPONSE with "help information required by the user' result value to the 
SIM with the identifier of the item for which the user is requiring help information. 

6.4.10 • SEND SHORT MESSAGE 

Two types are defined: 

. a short message to be sent to the network in an SMS-SUBMIT message, or an SMS-COMMAND message, 
where the user data can be passed transparently: 

a short message to be sent.to the network in an SMS-SUBMIT message where the text needs to be packed by the 
ME. 

w( i , ■ |, . • b "•-"'••d ' u v t $"'"« provided by the SIM shall not be longer than .160 characters. It shall use 

^T^^i^^^V^^ 8-bU octets, in accordance with GSM 03.38 [51. The data coding 
indication contained in the Data Coding Scheme byte shall hc "default alphabet". The tex, length (which ,s par o he 
SMS TPDU) g.ven by the SIM shall state the number of 7-bii characters <n the text string. Ihc command details shall 
indicate "packing not required". 

8-bit data Short Messaecs may be sent by the SIM. The command shall indicate packing not required The data coding 
Lllcattn contained inthc Data Coding Scheme byte shall be "8 bit". The string shall no, be longer than .40 bytes, and 
the length (in SMS TPDU) shall state the number of bytes in the string. 

II UCS2 is supported by the ML. 16-bit data Short Messages may be sent by the SIM. The text string provided by the 
SIM shall not be lonacr than 70 characters. It shall use the 16-bi, UCS2 alphabet format, m accordance with GSM 0.O8 
|5J. The text lontrlh (winch is par. of the SMS TPDU) given by the SIM shall state the number ol 16-bu characters m the 
text siring. The command details shall indicate "packing not required". . . 

SMS commands may be sent by the SIM. These shall count as packed .ex. message. The SMS TPDU from the SIM shall 
indicate SMS-COMMAND. The command details shall indicate "packing not required . 

Where parkin" by the MK is required, .he tex. string provided by the SIM shall not be longer than 160 characters. It 
h i use the SMS default 7-bit coded alphabet as defined in GSM 03.38 [5| with bit 8 sc. to 0. The text ength given by 
the SIM shall state the number of characters in the .ex. string. The ML shall pack the text string and modify the Data 
Coding Scheme byte to "default alphabet" in accordance with GSM 03.38 1 5 J. before submitting the message to the 
network. 

Optionally, the SIM may include in this command an alpha identifier. The use of this alpha identifier by the ME is 

described below'. . ,.. 

- If the alpha idemifier is provided by the SIM and is not a null data object, .he MR shall use it to inform the user. 
This is also an indication that the MR should notgivc any o.her information lo the user on ihc fact that the Mb is 
sundin- a short messaee. If an icon is provided by the SIM. the icon indicated in the command may be used by 
the ME to inform the user, in addition to, or instead of the alpha identifier, as indicaicd with the icon qual.I.er 
(see subclause 6.5.4). 

If the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), this is 
an indication that the ME should not give any information to the user on the fact that the ME is sending a shori 
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- If the alpha identifier is nol provided by the SIM, the ME may give information to the user concerning what is 
happening. 

If the ME is capable of SMS-MO, then it shall send the data as a Short Message TPDU to the destination address. The 
ME shall give the result to the SIM using TERMINAL RESPONSE (indicating successful or unsuccessful transmission 
of the Short Message) after receiving an SMS RP-ACK or RP-Error from the network. If an alpha identifier was 
provided by the SIM, the ME should not give any information to the user at the reception of SMS RP-ACK or RP-Error. 

If the Short Message TPDU is unsuccessfully received by the network (e.g. the reception of a CP-ERROR), the ME 
shall inform the SIM using TERMINAL RESPONSE (network currently unable to process command). If a null alpha 
identifier was provided by the SIM, the ME should not give any information to the user at the unsuccessful network 
reception. 

6.4.11 SENDSS 

Even if the Fixed Dialling Number service is enabled, the supplementary service control string included in the SEND SS 
proactive command shall not be checked against those of the FDN list. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

- if the command is rejected because the ME is busy on an SS transaction, the ME informs the SIM using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction); 

- if the command is rejected because the ME is busy on a USSD transaction, the ME shall inform the SIM using 
TERMINAL RESPONSE (ME unable to process command - currently busy on USSD transaction); 

- if the command is rejected because the ME does not.support that Supplementary Service, the ME informs the 
SIM using TERMINAL RESPONSE (Command beyond ME's capabilities). 

If the ME is able to send the SS request, the ME shall: 

- send the SS request immediately, without need to alert the user first; 

- optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by^the ME 
is described below: j 

- if the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the * 
user. This is also an indication that the ME should not give any other information to the user on the fact that 
the ME is sending a SS request. If an icon is provided by the SIM, the icon indicated in the command may be 
used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon 
qualifier (see subclause 6.5.4); 

- if the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), this 
is an indication that the ME should not give any information to the user on the fact that the ME is sending an 
SS request;. . ' 

- ' if the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 
happening. 

- once an SS Return Result message not containing an error has been received from the network, the ME shall 
inform the SIM that the command has been successfully executed, using TERMINAL RESPONSE. This 
command shall include the contents of SS Return Result as additional data. 

If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the 
reception of an SS Return Result message; 

- if the command is rejected because the network cannot support or is not allowing the Supplementary Service 
request, the ME informs the SIM using TERMINAL RESPONSE (SS Return Result error code). 

If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the 
reception of a SS Return Result message; . 
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- if the SS request is unsuccessfully received by the network, the ML shall inform the SIM using I LUMINAL 
RESPONSE (network currently unable to process command), and noi retry to send the request. 

If a null alpha identifier was provided by the SIM, the ML should not give any information to the user at the 

reception of a SS Return Result message, 
ir the ML supports the Last Number Dialled service, the ML shall not store in KF, NIJ the .supplementary service control 
string sent by the SIM in this command. 

6,4.12 SEND USSD. 

Upon receiving this command, the ML shall deeide if it is able to execute die command. Examples are given below, but 
the list is not exhaustive: 

- If the command is rejected because the ML is busy on a USSD transaction, the ME informs the SIM using 
TERMINAL RHSPONSK (ML unable to process command - currently busy on USSD transaction); 

- if the command is rejected because the Mli is busy on a SS transaction, the ML informs the SIM using 
TERMINAL RESPONSE (ME unable to process command - currenlly busy on SS transaction). 

. l; the ML is able to send the USSD request, the ME shall: 

send the USSD immediately, without need to alert the user first: 

optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME 
is described below: 

If the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the 
user W This is also an indication that "the ML should not give any other information to the user on the fact that 
the ME* is sending a USSD request. If an icon is provided by the STM, the icon indicated in the command may 
be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the 
icon qualifier (see subclause 6.5.4). 

- If the alpha identifier is provided by the SIM and is a null data object {i.e. length - '()()' and no value part), 
this is an indication that the Mli should not give any information to the user on the fact that the ME is sending 
a USSD request. 

If the alpha identifier is not provided by the SIM. the ME may give information to the user concerning what is 
happening. 

' - once the USSD transaction is initiated, a dialogue between the network and the user may occur which involves 
the MM I of the ML. If an alpha identifier was initially provided by the SIM. this alpha identifier may be 
discarded during this dialogue; 

once a RELEASE COMPLETE message containing the USSD Return Result message not containing an error has 
been received from the network, the ME shall inform the SIM that the command has been successfully executed, 
usin» TERMINAL RESPONSE. This command shall include the text contained in the USSD Return Result in a 
TcxuStrina data object. If a null alpha identifier was provided by the SIM. the ML should not give any 
information to the user at the reception of a USSD Return Result message; 

if the MS clears the transaction by sending a REI .EASE COMPLETE upon request of the user, the ML shall 
inform the SIM using TERMINAL RESPONSE (USSD transaction terminated by user); 

if the USSD operation is rejected because the network cannot support or is not allowing mobile initiated USSD, 
the ME informs the SIM using TERMINAL RESPONSE {USSD Return Result error code). If a null alpha 
identifier was provided by the SIM, the ME should not give any information to the user at the reception ol a 
USSD Return Resuit message; 

if the USSD request is unsuccessfully received by the network, the ME shall inform the SIM using TERMINAL 
RESPONSE (network currently unable to process command), and not retry to send the request. If a null alpha 
identifier was provided by the SIM, the ME should not give any information to the user at the reception of a 
USSD Return Result message. . 
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6.4.13 SET UP CALL 

Three types are defined: 

- sei up a call, but only if not currently busy on another call; 

- set up a calL putting all other calls (if any) on hold: 

- set up a call, disconnecting all other calls (if any) first. 

For each of these types, the SIM may request the use of an automatic red ial mechanism according to GSM 02.07 [I9|. 
The SIM may also request an optional maximum duration for the redial mechanism. The ME shall attempt at least one 
call set-up. 

In addition to the called party number, the command may contain capability configuration parameters (giving the bearer 
capability to request for the call) and the called party subaddress. The ME shall use these in its call set-up request to the 
network. The command may also include DTMF digits, which the ME shall send to the network after the call has 
connected. The ME shall not locally generate audible DTMF tones and play them to the user. 

NOTE: On the downlink audio, DTMF tones reflected by the network may be heard. 

It is possible for the SIM to request the ME to set up an emergency call by supplying the number " 1 12" as called parly 
number. If the SIM supplies a number stored in EF ECC , this shall not result in an emergency call. 

If the Fixed Dialling Number service is enabled, the number included in the SET UP CALL proactive command shall 
not be checked against those of the FDN list. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

- If the command is rejected because the ME is busy on another call, the ME informs the SIM using TERMINAL 
RESPONSE (ME unable to process command - currently busy on call); 

- If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM using ■ 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction); 

- If the command is rejected because the ME cannot support Call Hold, or because the ME does not support the 
capability configuration parameters requested by the SIM, the ME informs the SIM using TERMINAL 
RESPONSE (Command beyond ME's capabilities); 

- If the command is rejected because the network cannot support or is not allowing Call Hold of a multi parly call, 
the ME informs the SIM using TERMINAL RESPONSE (SS Return Result error code). 

- If the command is rejected because the network cannot support or is not allowing Call Hold of a single call, the 
ME informs the SIM using TERMINAL RESPONSE (Network currently unable to process command). 

If the ME is able to set up the call on the serving network, the ME shall: 

- Alert the user (as for an incoming call). This is the confirmation phase. 

- Optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME 
■ is described below : . 

If Second Alpha Identifier in SET UP CALL is supported by ME: 

- If the first alpha identifier is provided by the SIM and is not a null data object, the ME shall use it during 
the user confirmation phase. This is also an indication that the ME should not give any other information 
to the user during the user confirmation phase. If an icon is provided by the SIM, the icon indicated in the 
command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as 
indicated with the icon qualifier (see subclause 6.5.4). 

- If the first alpha identifier is not provided by the SIM or is a null data object (i.e. length = OT and no 
value part), the ME may give information to the user. 
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- If the second alpha identifier (i.e the one alter .he mandatory address object, is provided by the SIM land 
is no. a null data object, the MK shall use it during the call sel-up phase and during the call. I an .con ,s 
pr<;:!de! hv .he SIM. the icon indicated in the command may he used by the ME to m.orn, the user, m 
addition U>: or instead of the alpha iden.ifi.er. as indicated with the .con quahl.cr (see subclause fO.4,. 

. If the secondalpha identifier is no. provided by the SIM or is a null data objec..(i.e. length = '()()' and no 
value part), the Mli may give informal ion to the user. 

If Second Alpha Identifier in SI T UP CAI.l. is not supported by Mli: 

. ir the alpha identifier is provided by the SIM. the ME shall use it to inform the user, at the latest when the 
user is alerted The MK may also use it to inform the user during ,he call set-up. II an .corns provided by ,1k 
S?M the .con indicated in the eo.nn.and .my be used by .he Mli to inform the user, ,n add.non .<>. or .nstead 
of the alpha identifier, as indicated with the icon quahl.cr (sec subclause 6 5.4). 
,f the user accepts the call, the Mli shall then se, up a call to the des.mat.on address given in he response data. 
" w,.n tltc rllevaiu capability configuration parameters and called party subaddress (it provided by (he SIM): 

'.If the user does not accept the call, or rejects the call, then .he ME informs the SIM using TERMINAL 
RKSPONSL (user did not accept call set-up request). The operation is aborted: 

. If lhc user has indicated the need to end the proactive SIM session, the ME shall send a TERMINAL 

• RESPONSE with "Proactive SIM session terminated by the user' result value. 
, optionally, during call set-up, the Mli can give some audible or display indication concerning wha. is happening: 

(),k,. , CONNFCT message has been received from ,he network .defined in GSM 04.08), the Mli shall inform 
" ZsMmZ command has been successfully executed, using TERM IN AI . RESPONSE. Operat.on ol .he call 

then proceeds lis normal. 
If the first call set-up attempt is unsuccessful: 

. ,f ,he SIM did not request rcdial then the ME shall inform the SIM using TERMINAL RESPONSE (network 
currently unable lo process command), and not rcdial to sel-up the call: 

If the SIM requested redial, then the ME may automatically rcdial the call (depending on its 
a hUity/eo , juration). In this case, the ME shall no. send a command result to the SIM concerning he ,rs, o. 

tibs quen, laded set-up attempts. If the call set-up has no, been successiul, and the ML ,s ik. gomg to 
ncrform any more redials. or the time elapsed since the first call set-up attempt has exceeded the durat.on 
requested bailie SIM. then the ME shall inform the SIM using TERMINAL RESPONSE (network currently 
unable lo process command), and the redial mechanism shall be terminated: 

• " •'. lf lh c user stops the call se.-up attempt or the redial mechanism before a result is received from the network, the 
ME mfonns L SIM using TERMINAL' RESPONSE (user cleared down call before connection or network 
release). ... 

If lhc ME supports the Las. Number Dialled service, the ME shall no. store in EE,.™ the call se.-up details (called party 

number and associated parameters) sent by the SIM in this command. 

6,4.14 POLLING OFF 

This command disables the Proactive Polling (defined in GSM I I.I I [20]). SIM Presence Detection (defined in GSM 
• II. II |2()|) is not affected by this command. '- ■ ; ' ' 
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6.4.15 PROVIDE LOCAL INFORMATION 

This command requests the ME to send current local information to the SIM. At present, this information is restricted to: 

. - location information: the mobile country code (MCC), mobile network code (MNC), location area code (LAC) 
and cell ID of the current serving cell; 

- the [ME1 of the ME; 

- the Network Measurement Results and the BCCH channel list; 

- the current date, time and time /one; 

- the current ME language setting; 

- and the Timing Advance. 

The ME shall return the requested local information within a TERMINAL RESPONSE. Where location information or 
Network Measurement Results has been requested and no service is currently available, then the ME shall return 
TERMINAL RESPONSE (ME currently unable to process command - no service). Where location information or 
Network Measurement Results has been requested and the ME is on limited service (e.g. emergency calls only), the ME 
shall return the data requested in the TERMINAL RESPONSE with the general result (Limited Service). 

If the NMR are requested and a call is in progress, the value of all the returned parameters provided by the ME in the 
response to the command will be valid. The NMR returned when a call is in progress from MEs supporting multiband 
operation, shall be according to the value of the multiband reporting parameter as defined in GSM 04.08 |8|. If a call is 
not in progress (i.e. ME is in idle mode) some of the returned parameters (e.g. RXQUAL) may be invalid. In idle mode, 
MEs supporting multiband operation shall ignore the value of the multiband reporting parameter and the NMR returned 
shall be as defined in GSM 04.08 [8] when the multiband reporting parameter equals zero. 

NOTE 1 : When in idle mode, the only information element on which it is possible to rely on is the RXLEV-FULL- 
SER VING -CELL, which contains the value of the received signal strength on the BCCH of the current 
serving cell. 

NOTE 2: Network Measurement Results are defined in GSM 04.08 [8] as Measurement Results. 

The ME shall return the current date and time as set by the user. If available, the ME shall also return the time /.one 
known from the network with the NITZ feature (see GSM 02.42 [26 1). If the time zone information is not available, the 
ME shall return TF for this element. 

If language setting is requested, the ME shall return the currently used language. 

If the Timing Advance is requested, the ME shall return the timing advance value that was received from the BTS 
during the last active dedicated connection (e.g. for call or SMS). Timing advance is defined in GSM 04.08 [8|. An ME 
supporting the Timing Advance feature shall be able to store the last value of timing advance. In addition to the timing 
advance value, the ME shall return its current status (i.e. ME is in idle mode or not) in order for the application to be 
aware of potential misinterpretation of the liming advance value. Caution should be taken if using the Timing Advance 
value for distance measurement as reflections from the external environment (buildings etc.) may affect the accuracy. 

6.4.16 SET UP EVENT LIST 

The SIM shall use this command to supply a set of events. This set of events shall become the current list of events for 
which the ME is to monitor. 

Any subsequent SET UP EVENT LIST command replaces the current list of events supplied in the previous SET UP 
EVENT LIST command. The SET UP EVENT LIST command can also be used to remove the entire list of events 
current in the ME; see subclause 6.6. 1 6. The list of events provided by the SIM in the last SET UP EVENT LIST 
command shall be removed if the ME is powered off or the SIM is removed or electrically reset. 

When the ME has successfully accepted or removed the list of events, it shall send TERMINAL RESPONSE (OK) to 
the SIM. 

When the ME is not able to successfully accept or remove the list of events, it shall send TERMINAL RESPONSE 
(Command beyond ME's capabilities). 

When one of the events in the current list occurs, then the ME shall use the Event Download mechanism to transfer 
details of the event to the SIM; see clause 11. 
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6.4.17 PERFORM CARD APDU 

This subclause applies only if class V is supported. 

This command requests the MH to send an APDU command lo the additional card (Card x). 

The command includes: 

•• the additional card reader identifier, which is pan of ihe Device Identities object, 

- the APDU command to he performed. 

Upon receiving this command, the MH shall decide if it is able to execute the command: 

- If the command is rejected because the card reader identity is not valid, the MR informs the SIM using 
TERMINAL RESPONSE (MulliploCard command error - Card reader not valid): 

- If the command is rejected because the card reader is not presenl-or has been removed, the MH informs the SIM 
usinii TERMINAL RHSPONSH (MultipleCard command error • Card reader removed or not present): 

- If the command is rejected because the card is not present or has been removed, the MH informs the SIM using 
TERMINAL RHSPONSH (MultipleCard command error Card removed or not present): ' 

- If the command is rejected because the card reader is busy, ihe MH informs the SIM using THRMINAI . 
RHSPONSH (MultipleCard command error - Card reader busy); 

- ' li the command is rejected because the card is not powered on, the MH informs the SIM using TERMINAL 

RHSPONSH (MultipleCard command error - Carti powered off): 

- If the command is rejected because (he received C-APDU format is not valid, the Mii informs the SIM using 
TERMINAL RHSPONSH (MultipleCard command error - C-APDU format error). 

If the MH is able to transfer die C-APDU to the addressed card, the MH shall: 

Transfer the C-APDU to the addressed card, through the selected MH- Card x protocol; 

- Extract the R-APDU data from the addressed card if so requested by the SIM; 

- If the command fails because no response is received from Card x, the Mli informs the SIM using TERMINAL 
RESPONSE (MultipleCard command error - Card mute): 

. If the command fails because of any form of transmission error, the ME informs the SIM using TERMINAL 
RESPONSE (MultipleCard command error -Transmission error): 

- II" ihe command fails because the MH does not support the protocol used by Card x, the MH informs the SIM 
usina TERMINAL RESPONSE (MultipleCard command error - Protocol not supported). 

If the command is performed successfully from a protocol point of view, the ME shall include the R-APDU within the 
TERMINAL RESPONSE command. • ' 

6.4.18 POWER OFF CARD . . 

This subclause applies only if class "a" is supported. 

' This command requests the ME to close a session with the additional card (Card x). , 

The command includes the additional card reader identifier, which is pari of the Device Identities object. 

Upon receiving this command, the ME shall decide if it is able to execute the command: 

■ ' If the command is rejected because the card reader identity is not valid, the ME informs the SIM using 
TERMINAL RESPONSE (MultipleCard command error - Card reader not valid); 

- If the command is rejected because the card reader is not present or has been removed, the ME informs Lhe SIM 
usins TERMINAL RESPONSE (MultipleCard command error - Card reader removed or not present); 
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- If the command is rejected because the card is not present or has been removed, the ME informs the SIM using 
TERMINAL RESPONSE (MultipleCard command error - Card removed or not present); 

- If the command is rejeeied because the card reader is busy, the ME informs the SIM using TERMINAL 
RESPONSE (MultipleCard command error - Card reader busy). 

If the ME is able to execute the command, the addressed Card x shall be deactivated according to ISO/IEC 78 16-3 [16]. 

6.4.19 POWER ON CARD 

This subclause applies only if class "a" is supported. 

This command requests the ME to start a session with the additional card (Card x). 

The command includes the additional card reader identifier, which is part of the Device Identities object. 

Upon receiving this command, the ME shall decide if it is able to execute the command: 

- If the command is rejected, because the card reader identity is not valid, the ME informs the SIM using 
TERMINAL RESPONSE (MultipleCard command error - Card reader not valid); 

- If the command is rejected because the card reader is not present or has been removed, the ME informs the SIM 
using TERMINAL RESPONSE (MultipleCard command crTor - Card reader removed or not present); 

- If the command is rejected because the card is not present or has been removed, the ME informs the SIM using 
TERMINAL RESPONSE (MultipleCard command error - Card removed or not present); 

- If the command is rejected because the card reader is busy, the ME informs the SIM using TERMINAL 
RESPONSE (MultipleCard command error - Card reader busy). 

If the ME is able to execute the command, and the addressed Card x is powered off, the ME shall activate the addressed 
Card x according to ISO/IEC 7816-3 116|. If the addressed Card x is already powered on, the ME shall treat the 
POWER ON CARD command as a warm reset, as defined in ISO/IEC 78 1 6-3 [ 16]. % 

The ME shall return the Answer To Reset within the TERMINAL RESPONSE command. If no ATR is received, the 
ME shall inform the SIM using TERMINAL RESPONSE (MultipleCard command error - Card mute). 

Application writers arc advised that the Card x should not be powered up for longer than necessary due to battery life 
considerations. 

6.4.20 GET READER STATUS 

This subclause applies only if class"a" is supported. 

This command requests the ME to get information about all interfaces or the indicated interface of additional card 
reader(s). This information is restricted to : 

- card reader status; 

- card reader identifier. 

The ME shall return the requested information from the interfaces to additional card reader(s) within a TERMINAL 
RESPONSE command. 

6.4.21 TIMER MANAGEMENT 

This command requests the ME to manage timers running physically in the ME. The possible actions on timers arc 
defined below : 

- start a timer; t . . • . 
. - deactivate a timer; • 

- get the current value of a timer. 
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The SIM unci .he MF are able to manage H different timers running in parallel. The possible duration of a limer is 

relied upon in nil eases 
deaelivaied in the MLi 



due lo potential MK aeiivu.es. When the MR is switched off or the SIM is reset, all timers are 



For a given timer, ... . • . . 

mlion uV SIM reuuesis the ME to start the timer with a duration, then : . 
"• , Ml ! . r he timer with the duration given by the SIM. even if this timer is already runnmg. When a 
tinier is e akes the value given by the SIM. and ,s then dccremen.cd. The MP. shall m.onn the SIM 
tote^nnd has been successfully executed, using TERMINAL RESPONSE (OK,. 

' when ihe SIM reuuesis the Mli to deactivate the timer, then : 
" e ttmcr is mnnin... the MK shall deactivate the time, This prevents the SIM from reeeivmg unnecessary 

t£2to * the expiration of . timer. The MB shall the current value oT the tuner (t.e. the durat.on that 

.. s?^^^ — » • 

contradiction with the current timer state ). 

when the SIM requests the MK to act the current value of the timer, then : 

it the tinier tannine, the MF. shall pass the current value of the tuner the durat.on that remams he.ore 
the tinier elaoses) to the SIM. using TERMINAL RESPONSE. 

?, Z thner ts ^activated. the Mli shall inform the SIM using TERMINAL RESPONSE ('aC.on ,n 

contradiction with the current timer stale'). 
When a timer expires (i e reaches zero), the ML shall use the Timer Expiration mechanism to transfer .he identifier of 
2 tune, Z haTex,,i!ed'and the difference between the tune when tins transfer occurs and me ume wnen ,ne umer was 
initially started. The MP. shall then deactivate the timer. 

6.4.22 SET UP IDLE MODE TEXT 

The SIM shall supply a text string, which shall be displayed by the ME as an idle mode text if the MF. is able to do it. 
■ e p esc a ion sfyle is left as an implementat.on decision to the MP. manulacturer. I he .die mode text si a 1 be 
cfep.ayecnn !, manner that ensures that neither the network name nor the serv.ee providers name are al.ected. 

If idle mode text is competin, with other mformulion to be displayed on the same area, lor instance u CB message, the 
• i IXtext shin be /eplacTed by the other information, ft is up to the ML to restore the ,dle mode text when the other 
information has no longer to be displayed. 

The text shall be removed from the MK's memory and display if either: 

- the MR is powered off or; . , 

- the SIM is removed or electrically reset or; 

- a Riil ; RI:SH command occurs with "initialisation" or "reset". 

he viiir»ni SI T t JP [DLL MODL TLXT command replaces the current idle mode text of the previous SET UP 
^HtSTlSrTsCT wmUi MODH THXT command can also be used to remove an idle mode text iron, 
the MR; see subclause 6.6.22. 

When the MF. has successfully integrated or removed an idle mode text, it shall send TERMINAL RESPONSL (OK) to 
the SIM. 

When the ML is not able to successfully integrate or remove the idle mode text: ,, shall send TERMINAL RESPONSE 
"Command beyond MK's capabilities" to the SIM. •■ 

6.4.23 RUN AT COMMAND . 

. .This subclause applies only if class "b" is supported by the-ML and enabled by .he subscriber through the ME. 
' The SIM uses this command to send an AT Command to the ML as though initiated by an attached I E. The ME shall 
then return an AT Response within a TERMINAL RESPONSE to the SIM. 
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If this feature is enabled, the SIM uses this command to send an AT Command to the ME as though initiated by an 
attached TE. The ME shall then return an AT Response within a TERMINAL RESPONSE to the SIM. 

ir this feature is disabled or the mobile does not support the RUN AT COMMAND, then if the SIM Application Toolkit 
receives an instruction from the network to issue the command, the SIM Application Toolkit should return an error 
indication in accordance with the AT Response set (e.g. as indicated in GSM 07.07 (27 1) to the network. 

Optionally, the SIM may include in this command an alpha identifier. The use of this alpha identifier by the ME is 
described below: 

if the alpha identifer is provided by the SIM and is not a null data object, the ME shall use it to inform the 
user. This is also an indication that the ME should not give any other information to the user on the fact that 
the ME is performing an AT command. If an icon is provided by the SIM, the icon indicated in the command 
may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with 
the icon qualifier (see subclause 6.5.4); 

if the alpha identifier is provided by the SIM and is a null data object (i.e. length = '()()' and no value part), this 
is an indication that the ME should not give any information to the user on the fact that the ME is performing 
an AT command; 

if the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 
happening. 

6.4.24 SEND DTMF 

This command requests the ME to send a DTMF string after a call has been successfully established either by the 
proactive command SET UP CALL or the user. This command is independant of sending DTMF within the call set up 
(as defined in the SET UP CALL command) and therefore, can be used at any time during a call. 

The ME shall not locally generate audible DTMF tones and play them to the user. 

NOTE: On the downlink audio, DTMF tones reflected by the network may be heard. i- 

It shall be possible for the user to deactivate this command. 

The sending of a DTMF string applies only to the currently active call. 

The TERMINAL RESPONSE indicating that the command has been performed successfully shall be sent after the 
complete DTMF string has been sent to the network by the ME. 

If the command is sent in idle mode, or a call is terminated or put on hold before the complete DTMF string has been 
sent to the network, the ME shall inform the SIM using TERMINAL RESPONSE '20' with the additional information 
"Not in speech call". 

If the user indicates the need to end the proactive SIM application session whilst the ME is sending the DTMF string, 
the ME shall stop sending the DTMF string and shall send a TERMINAL RESPONSE with "Proactive SIM application 
session terminated by the user" result value. 

Optionally, the SIM may include in this command an alpha identifier. The use of this alpha identifier by the ME is 
described below: 

- if the alpha identifer is provided by the SIM and is not a null data object, the ME shall use it to inform the 
user. This is also an indication that the ME should not give any other information to the user on the fact that 
the ME is performing a SEND DTMF command. If an icon is provided by the SIM, the icon indicated in the 
command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as 
indicated with the icon qualifier (see subclause 6.5.4); 

- if the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), this 
is an indication that the ME should not give any information to the user on the fact that the ME is performing 
a SEND DTMF command. 

If the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 
happening. 
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(GSM 11.14 version 8.3.0 Release 19S9) 

6 4 25 LANGUAGE NOTIFICATION , . . .. 

m . SIM sta „ . * « - » »«v - « *» * — - r " *" 

commands or envelope command responses. 
LANGUAGE NOTIFICATION command. 

speeir,eI.AN(iU7\(iHN()l'll'lCATK)N. ' 
Two types of language notification are defined: 

«ccific where an additional Language object shall be included by .he SIM: 
' rn '^eS where no Language object shall be included by the SIM. 

^,,essol^ 

(OK).u>theSIM. ■ • 

• a sir i \AC\i NOTIFICATION as appropriate. For instance, this could oe 

E^r^ssst^**- »■* mh mmi s,m T "*' " ,e 8 - 

6 4 26 LAUNCH BROWSER 

the list is not exhaustive: 

, ' rciectcd because the browser on the ML is busy or not available the MK informs the SIM 
' SSSSH unable U> process command - browser unavadable : . 

, • • , vl heciusc the MM is busy on a SS transaction, the ML informs the SIM using 
- ^mTnTSSSS? (ML tnuiblc to proeess'eommand - ML currently unable to process command,: 

, ■ ■ , , h ,-H.se the bearer provided in the command i.s not available, the ML informs the SIM 

If the ML is able to execute die command: 
. . lh e MH shall inform the S.M that the.command has bee, successfully taken into account, using TERMINAL 
RESPONSE; 
- the SIM shall end the proactive session; 
. the ML shall request content using the URL. 

provisionals data defined in [32] for exemple. 

Thc way the ME requests content using the URL is ou, of the scope of the present document. This is speeded ,n 
RFC 1 738 1 32 1 Annex K for example, ■ ■ • 

• N(mi: , There is a maximum w.e for .the URL that can be given in argument of,his proactive command. 

. 6 .4.27 OPEN CHANNEL • 

This subclause applies only if class V is supported. . . . . , 

' ' . ,he ME shall decide if it is able to execute the command. Thc SIM shall indicate whether 

' The SIM provides to the ML a list of parameters necessary to establish a link: 
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The SIM may request the use of an automatic reconnection mechanism according to GSM 02.07 1 19|. The SIM may 
also request an optional maximum duration for the reconnection mechanism. The ME shall attempt at least one link 
' establishment set-up. 

The SIM may also request an optional maximum duration for the ME to automatically release the link if no data is 
exchanged. 

If the Fixed Dialling Number service is enabled, the address included in the OPEN CHANNEL proactive command 
shall not be checked against those of the FDN list. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

- If immediate link establishment is requested and the ME is unable to set-up a channel using the exact parameters 
provided by the SIM, the ME informs the SIM of the best supported parameters using TERMINAL RESPONSE 
(Command beyond ME's capabilities). The operation is aborted; 

- If immediate link establishment is requested and the ME is unable to set-up the link with the network using the 
exact parameters provided by the SIM, the ME informs the SIM using TERMINAL RESPONSE (Network 
currently unable to process command). The operation is aborted; 

- If on demand link establishment is requested and the ME is unable to set-up a channel using the exact parameters 
provided by the SIM, the ME sets up the channel using the best parameters it can support and informs the SIM of 
the channel identifier and the modified parameters using TERMINAL RESPONSE (Command performed with 
modification); 

- If the command is rejected because the ME has no channel left with the requested bearer capabilities, the ME 
informs the SIM using TERMINAL RESPONSE (Bearer independent protocol error). The operation is aborted; 

- If the user does not accept the channel set-up, the ME informs the SIM using TERMINAL RESPONSE (User did 
not accept call set-up request). The operation is aborted; 

- If the user has indicated the need to end the proactive SIM session, the ME informs the SIM using TERMINAL 
RESPONSE(Proactive SIM session terminated by the user). The operation is aborted; 

- If the command is rejected because the ME is busy on another call, the ME informs the SIM using TERMINAL 
RESPONSE (ME unable to process command - currently busy on call). The operation is aborted; 

- If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction). The operation is 
aborted; 

The ME shall inform the SIM that the command has been successfully executed using TERMINAL RESPONSE: 

- If immediate link establishment is requested, the ME allocates buffers , sets up the linkand informs the SIM and 
reports the channel identifier using TERMINAL RESPONSE (Command performed successfully); 

- If on demand link establishment is requested; the ME allocates buffers, informs the SIM and reports the channel 
identifier using TERMINAL RESPONSE (Command performed successfully); 

If the ME is able to set up the channel on the serving network, the ME shall: 

- Alert the user (as for an incoming call). This is the confirmation phase. ■ 

- Optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME 
is described below : 

- If the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it during the 
user confirmation phase. This is also an indication that the ME should not give any other information to 
the user during the user confirmation phase. If an icon is provided by the SIM, the icon indicated in the 
command may be used by the ME to inform the user ; in addition to, or instead of the alpha identifier, as 
indicated with the icon qualifier (sec subclause 6.5.4). . . 

- If the alpha identifier is not provided by the SIM or is a null data object (i.e. length =,'00' and no value 
part), the ME may give information to the user. 
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If the user accepts the channel, ihe ME shall then sci up a channel; 

- If the user does nol accept the channel or rejects the channel, ihen ihe MF informs 'the SIM using TERMINAI - 
RESPONSE l user did not accept caii set-up request). The operation is aborted: 

If the user has indicated the need to end the proactive SIM session, the ME shall send a TERMINAL 
RESPONSE with (Proactive SIM session lenninated by the user) result value. 

Optionally, during call set-up. ihe MH can give some audible or display indication concerning whal is happening: 
II ihe first link set-up attempt is unsuccessful:' 

If the SIM did not request link re-connection then the ME shall inform the SIM using TERMINAL RESPONSE 
(network currently unable to process command), and not retry to set-up the link; 

- If the SIM requested link re-connection, then the ME may automatically retry to set-up the link (depending on its 
configuration capabilities). In this case, the ME shall not send a command result to the SIM concerning the first 
or any subsequent Failed set-up attempts. If the link set-up has nol been successful, and the ME is not going to 
perform anv more re-tries, or the time elapsed since the first link set-up attempt has exceeded the duration 
requested by the SIM, then the ME shall inform the SIM using TERMINAL RESPONSE (network currently- 
unable to process command), and the re-try mechanism shall be terminated: 

- ' If the user stops the link set-up attempt or the re-try mechanism before a result is received from the network, the 
ME informs the SIM using TERMINAL RESPONSE (user cleared 'down call before connection or network 
release). 

If the Mli supports the i .asl Number Dialled service, the Mii shall not store in U1-,. N „ the channel set-up details (called 
party number and associated parameters) sent by the SIM in this command. 

6.4.28 CLOSE CHANNEL 

• This subclause applies only if class "e" is supported. 
This command requests the ME to close the channel corresponding to the Channel identifier. . 
Upon receiving this command, the ME shall decide if it is able to execute the command: 

- If the command is rejected beeause the channel identifier is not valid, the ME informs the SIM using 
TERMINAL RESPONSE (Bearer independent protocol error); 

- If the command is rejected beeause the requested channel is in error, the ME informs the SIM using TERMINAL 
RESPONSE (Bearer independent protocol error); 

If the ME is able to process the command: 

- the ME shall release the link, discard the remaining data and inform the SIM that the command has been 
successfully executed, using TERMINAL RESPONSE; 

- Optionally, during CLOSE CHANNEL, the ME can give some audible or display indication concerning whal is 
happening.' In this intention, the SIM may include in tins command an alpha-identifier. The use of this aipha- 
identifier by the ME is described below: ... ... 

- If the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to indicate the 
link closing phase, if an icon is provided by the SIM, the icon indicated in the command may be used by the 
ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon qualifier 
(see subclause 6.5.4). 

- If the alpha identifier is not provided by ihe SIM or is a null data object (i.e. length = W and no value part), 
the ME may give information to the user. 

6.4.29 RECEIVE DATA , - . . . 

This subclause applies only if class V is supported. 
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This command requests the ME to return data from a dedicated Channel identifier according to the number of bytes 
specified by the SIM. 

Upon receiving this command, the ME shall return the data available in the Rx buffer corresponding to the Channel 
identifier. Examples are given below, but the list is not exhaustive: 

If the ME is unable to process the command: 

- If the command is rejected because the requested channel is already closed the ME informs the SIM using 
TERMINAL RESPONSE (Bearer independent protocol error); 

- If the user has indicated the need to end the proactive SIM session, the ME informs the SIM using TERMINAL 
RESPONSE (Proactive SIM session terminated by the user). 

If the ME is able to process the command: 

- If the requested number of bytes is available in the buffer, the ME shall inform the SIM that the command has 
been successfully executed, using TERMINAL RESPONSE and return the requested data and the number of 
bytes remaining in the channel buffer (or FF if more than the maximum bytes remains). 

- If the requested number of bytes is not yet available in the buffer, the ME shall NOT wait for the requested 
number of bytes to arrive. The ME shall inform the SIM, using TERMINAL RESPONSE (Command performed 
with missing information) and returns the data currently available in the channel buffer. 

- in the case of structured transmission, the structure of the service data unit received by the ME shall be kept 
intact and shall be fully respected while receiving. The size of service data unit included in the packet PDU is 
therefore limited to the maximum size of "channel data" in "receive data" response. The ME shall put only one 
complete service data unit in RX buffer at one time and wait for the RX buffer to be empty before sending the 
next user data unit. Then the SIM shall receive all "channel data" in one "receive data" command. The SDU is 
therefore limited to the maximum size of channel data suing in terminal response. 

- If the alpha identifier is provided by the SIM, the ME shall use it to inform the user. The ME may also use it to 
inform the user during data transfer. If an icon is provided by the SIM, the icon indicated in the command may be 
used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon 
qualifier (see subclause 6.5.4). 

6.4.30 SEND DATA 

This subclause applies only if class V is supported. 

This command requests the ME to send data through a previously set up data channel corresponding to a dedicated 
Channel identifier. The SIM informs the ME if the data is : 

- to be sent immediately; 

- or to be stored in a Tx buffer. Then it is up to the ME to manage the data sending in order to use the bearer in an 
optimised way. 

Upon receiving this command, the ME shall either immediatly send data or store provided data into' the Tx buffer 
corresponding^ the Channel identifier. Examples are given below, but the list is not exhaustive: 

- If the ME is unable to process the command: 

If the command is rejected because the requested channel is already closed the ME informs the SIM using 
TERMINAL RESPONSE (Bearer Independent Protocol error); 

- If the command is rejected because the channel is temporarily unavailable the ME informs the SIM using 
TERMINAL RESPONSE (ME currently unable to process command); 

- If the requested number of bytes of empty space is not yet available in the buffer the ME informs the SIM 
using TERMINAL RESPONSE (Bearer Independent Protocol error); 

- If the user has indicated the need to end the proactive SIM session, the ME informs the SIM using 
TERMINAL RESPONSE (Proactive SIM session terminated by the user). 
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- If the ME is able to process the command: 

- If the requested number of bytes of empty space is available in the buffer the ME shall inform the SIM that 
the command has been successfully executed, using TERMINAL RESPONSE and return the number of bytes 

' of empty space available in the Tx buffer (or FF if more then 255 bytes are available). 

- in the case of structured transmission , the structure of the service data unit sent by the application shall be 
kept intact and shall be fully respected while sending. The size of service data unit in the packet PDU is 
therefore limited to the size of "channel data" in the send data command. The SIM application shall send user 
data unit in one send data command. Then the ME shall send "channel data" in one packet PDU. The SDU is 
therefore limited to the maximum size of channel data string in data send command. 

- If the alpha identifier is provided by the SIM, the ME shall use it to inform the user. The ME may also use it 
to inform the user during data transfer. If an icon is provided by the SIM, the icon indicated in the command 
may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with 
the icon qualifier (see subclause 6.5.4). 

6.4.31 GET CHANNEL STATUS 

This subclause applies only if class "e" is supported. 

Tins command requests the ME to return a Channel status data object for each dedicated Channel identifier. The ME 
shall return the requested information concerning the channel(s) within a TERMINAL RESPONSE command. 

6.5 Common elements in proactive SIM commands 

6.5.1 Command number 

The command number is to cater for the future possibility of multiple ongoing commands (i.e. when the SIM issues 
further commands before receiving the response to the ongoing command). The implications of such multiple ongoing 
commands have not been elaborated at this stage of the toolkit specification. 

Each command issued by a proactive SIM during a GSM session shall have its own command number. Command 
numbers may take any hexadecimal value between 'OF and 'FE\ The command number is held in the command details 
data object. 

The SIM is responsible for assigning the command number. 

The ME shall keep a record of the status of each command and its command number, until the ME gives the result of the 
command to the SIM, using TERMINAL RESPONSE. After this, the ME may erase all internal records concerning this 
command. The command number is then free for allocation by the SIM to a new command. 

When the MS is powered off and on, the details of any ongoing command shall be reset. The ME shall not be expected 
to know the status of commands issued in a previous GSM session. 

6.5.2 Device identities 

This data object gives the devices which are the source and destination for the instruction. Only certain combinations of 
source and destination devices are allowed for each proactive command. These are given in clause 14 of this document. 

6.5.3 Alpha identifier 

Many of the commands include an alpha identifier data object. This is intended to be a short one or two word identifier 
which shall be displayed on screen by the ME at the same time as the SIM command is performed. If longer text strings 
arc required to be displayed on the screen, the SIM shall send a separate DISPLAY command. 
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6.5.4 Icon identifiers 

Some commands may provide an icon identifier. Icons are intended to enhance the MMI by providing graphical 
information to the user. The display of icons is optional for the ME. If icons are provided by the SIM, the related alpha 
identifier or text string shall be present and not a null string. 

The SIM indicates to the ME whether the icon replaces an alpha identifier or text string, or whether it accompanies it 
(see subclause 12.32). 

If both an alpha identifier or text string, and an icon are provided with a proactive command, and both are requested to 
be displayed, but the ME is not able to display both together on the screen, then the alpha identifier or text string takes 
precedence over the icon. 

If the SIM provides an icon identifier with a proactive command, then the ME shall inform the SIM if the icon could not 
be displayed by sending the general result "Command performed successfully, but requested icon could not be 
displayed". 

If the ME receives an icon and either an empty, or no, alpha identifier/text string is given by the SIM, than the ME shall 
reject the command with general result "Command data not understood by ME". 

NOTE: Application designers should be aware that icons provided by the application may not be displayed by the 
ME. 

6.6 Structure of proactive SIM commands 

The general structure of proactive SIM commands using TLV objects is described in annex D, 

6.6.1 DISPLAY TEXT 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E) 




M 


. Y 


1 or 2 


Command details 


12.6 


M 


Y 


Ar 


Device identities 


12.7 


M 


Y 


B 


Text string 


12.15 


M 


Y 


C 


Icon identifier 


12.31 


O 


N 


D 


Immediate response 


12.43 


O 


N 


E 



6.6.2 GET INKEY 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Text string 


12.15 


M 


Y 


C 


Icon identifier 


12.31 


• O 


N 


D 



Text string 

Contents: text for the ME to display in conjunction with asking the user to respond. 
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6.6.3 



Description 


oeciion 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


I 


Length (A+B+C+D+E+F) 




M 


Y 


» 1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y' 


B 


Text string 


12.15 


M 


Y 


C 


Response length 


12.11 


M 


Y 


D 


Default Text 


12.23 


0 


N 


E 


Icon identifier 


12.31 


0 


N 


F 



Tsxt strin** 

Contents: text forthe ME to display in conjunction with asking the user to respond. 
-.. Response length 

Contents: the minimum and maximum acceptable lengths for the response trom the user. 
Contend text for the ME to display, corresponds to a default text string offered by the SIM. 

6.6.4 MORE TIME 



6.6.5 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 




M 


Y 


1 or.2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


PLAY TONE 






Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 . 


M 


Y 


1 


Length (A+B+C+D+E) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


• B 


Alpha identifier 


12.2 


0 


N 


C 


Tone 


12.16 


0 


N 


D 


Duration 


12.8 


0 


N 


E 



Joints: the standard supervisory tone or proprietary ME tone that the ME shall generate, either on its own or 
on top of the downlink audio path. If no tone is specified, then the ME shall default to general beep . 

NOTE: Some supervisory tones arc optional For mobile equipment (see GSM 02.40 [18]). 

Contents- the length of time for which the ME shall generate the tone, if the tone is continuous or repeatable For 
single tones, the value of this data object shall be .gnored by the ME. If no duration is specified, the ME shall 
default to a duration determined by the ME manufacturer. 
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6.6.6 POLL INTERVAL 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


. M 


Y 


1 


Length (A+B+C) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Duration 


12.8 


M 


Y 


C 



- Duration 

Contents: the maximum interval between two STATUS commands related to Proactive Polling. 

6.6.7 SET-UP MENU 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D1+D2+...Dn+E+F+G) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


M 


Y 


C 


Item data object for item 1 


12.9 


M 


Y 


D1 


Item data object for item 2 


12.9 


O 


N 


D2 




12.9 


O 


N 


Dx 


Item data object for last item in list 


12.9 


O 


N 


Dn 


Items Next Action Indicator 


12.24 


O 


N 


E 


Icon identifier 


12.31 


O 


N 


F 


Item Icon identifier list 


12.32 


O 


N 


G 



The SET-UP MENU command BER-TLV data object shall contain Item SIMPLE-TLV data objects. Each Itcm'data 
object contains an item in the list, for the user to choose. The length of each Item data object may be different. Within a 
list, each Item shall have a unique item identifier. 

If the "Item data object for item 1 " is a null data object (i.e. length = '00' and no value part), this is an indication to the 
ME to remove the existing menu from the menu system in the ME. 

If the SIM provides an Items Next Action Indicator data object, the comprehension required flag shall be set to *0\ 

The SIM may provide a title icon identifier data object and/or an item icon identifier list data object. The item icon 
identifier data object contains an icon identifier for each item. 
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Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


. Y • 


1 


Length (A+B+C+D1+D2+...Dn+E+F+G+H) 


... 


M 


- Y 


1 or 2 


Command details 


12.6 


M 


Y. 


A 


Device identities 


127 


M 


Y 


B 


Alpha identifier 


12.2 


0 


N 


C 


Item data object for item 1 


12.9 


M 


Y 


D1 


Item data object for item 2 




o 

w 


N 


D2 




12.9 


O 


N • 


Dx 


Item data object for last item in list 


12.9 


0 


N 


Dn 


Items Next Action Indicator 


12.24 


0 


N 


E 


Item Identifier 


12.10 


0 


N 


F 


Icon identifier 


12.31 


0 


N 


G 


Item Icon identifier list 


12.32 


0 


N 


H 



The SELECT ITEM command BER-TLV data object shall contain Item SIMPLE-TLV data objects. Each Item data 
object contains an item in the list, for the user to choose. The length of each Item data object may be d.fferent. Within a 
list each Item shall have a unique item identifier. The SELECT ITEM command BER-TLV data object may contain a 
single Item Identifier data object as an indication of the default item. The Comprehension Required flag in the Item 
Identifier data object shall be set to 0, indicating that it is not mandatory for the ME to support indication of the default 
item. 

If the SIM provides an Items Next Action Indicator data object, the comprehension required flag shall be set to '0'. 

The SIM may provide a title icon identifier data object and/or an item icon identifier list data object. The item icon 
identifier data object contains an icon identifier for each item. 

6.6.9 SEND SHORT MESSAGE 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E+F) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


O 


N 


C 


Address 


12.1 


0 


N 


D 


SMS TPDU (SMS-SUBMIT or SMS- 
COMMAND) 


12.13 


M 


Y 


E 


Icon identifier 


12.31 


O 


N 


F 



The address data object holds the RP_Destination_Address of the Service Centre. If.no RP_Destination_Addrcss is 
transferred, then the ME shall insert the default Service Centre address. 
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6.6.10 SENDSS 



Description 


Section 


IVI/VJ 


Min 


Length 


Proactive SIM command Tag 




IVI 


y 


1 


Length (A+B+C+D+E) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


O 


N 


C 


SS string 


12.14 


M 


Y 


D 


Icon identifier 


12.31 


O 


N 


E 



6.6.11 SENDUSSD 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


O 


N 


C 


USSD String 


12.17 


M 


Y 


D 


Icon identifier 


12.31 


O 


N 


E 



6.6.12 SET UP CALL 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E+F+G+H+l+J) 




M 


Y 


1 or 2 


Command details j 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier (user confirmation phase) 


12.2 


O 


I N 


C 


Address 


12.1 


M 


Y 


d : 


Capability configuration parameters 


12.4 


O 


N 


E 


Called party subaddress 


12.3 


O 


N 


F 


Duration 


. 12.8 


0 


N 


G 


Icon identifier (user confirmation phase) 


12.31 


o 


N 


H 


Alpha identifier (call set up phase) 


12.2 


o 


N 


I 


Icon identifier (call set up phase) 


12.31 


o 


N 


J 



If the capability configuration parameters arc not present, the ME shall assume the call is a speech call. 

If the called party subaddress is not present, the ME shall not provide a called party subaddress to the network. 

If the duration is not present, the SIM imposes no restrictions on the ME of the maximum duration of redials. 

6.6.13 REFRESH 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


File List 


12.18 


M/O 


N 


C 



For the refresh modes "File Change Notification" and "SIM Initialization and File Change Notification", the SIM shall 
supply a File List data object, indicating which EFs need to be refreshed. For other modes, inclusion of a File List is 
optional, and the ME shall ignore it. 
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Description 


Section 


. M/O 


Min 


Length 


Proactive SIM command Tag . 


13.2 


M 


Y 


1 


Length (A+B) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y . 


B 



6.6.15 PROVIDE LOCAL INFORMATION 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M . 


Y 


B 



6.6.16 SET UP EVENT LIST 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 




M 


Y 


1 or 2 


Command details 


12.6 


.M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 


Event list 


12.25 


M 


Y 


C 



If the Event list is a null data object (i.e. length = W and no value part), this is an indication to the ME to remove the 
existing list of events in the ME. 

6.6.17 PERFORM CARD APDU 

' This subclause applies only if class "a" is supported. 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


• Y 


A 


Device Identities 


12.7 


M 


Y 


B 


C-APDU 


12.35 


M 


Y 


C 



6.6.18 POWER OFF CARD 

This subclause applies only if class "a" is supported. 



Description 


.Section 


M/O . 


. Min 


* Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y . 


A 


Device Identities 


12.7 


M 


Y 


B 



6.6.19 POWER ON CARD 

This subclause applies only if class "a" is supported. 
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Description 


Spction 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 



6.6.20 GET READER STATUS 

This subclause applies only if class "a" is supported. 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


L A 


Device Identities 


12.7 


M 


Y 


B 



6.6.21 TIMER MANAGEMENT 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 


Timer Identifier 


12.37 


M 


Y 


C 


Timer value 


12.38 


M/O 


N 


D 



- Timer Identifier 

Contents: identifier of the timer to which the command applies. 

- Timer value 

Contents: length of time during which the timer has to run. The SIM shall supply this data object only .when a 
timer has to be started. 

6.6.22 SET UP IDLE MODE TEXT 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


12.2 


M 


Y 


1 


Length (A+B+C+D) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Text string 


12.15 


M 


Y 


C 


Icon identifier 


12.31 


O 


N 


D 



If the "Text string" is a null data object (i.e. length = '00' and no value part), the ME shall remove the existing idle mode 
text in the ME. 

6.6.23 RUN AT COMMAND 

This subclause applies only if class "b" is supported. 
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Description 




M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E) 




M 


Y 


1 or 2 


Command details 




M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


O 


' N 


C 


AT Command 


12.40 


. M 


Y 


D 


Icon identifier 


12.31 


O 


N 


E 



6.6.24 SEND DTMF COMMAND 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1, 


Length (A+B+C+D+E) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 


Alpha Identifier 


. 12.2 


O 


. N 


C 


DTMF String 


12.44 


M 


Y 


D 


Icon identifier 


12.31 


O 


N 


E 



6.6.25 LANGUAGE NOTIFICATION 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 




M 


Y 


1 


Command details 


12.6 . 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Language 


12.45 


M/O 


Y/N 


C 



Contents: Currently used language. The SIM shall include a Language object, when a specific language is being 
notified. 

6.6.26 LAUNCH BROWSER 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E+F1+ F2+...+FN+G) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 


Browser Identity 


12.47 


O 


N 


C 


URL 


12.48 


M 


Y 


D 


Bearer 


12.49 


O 


N 


E 


Provisioning File Reference 1 


12.50 


O 


N • 


F1 


Provisioning File Reference 2 


12.50 


O 


N . 


F2 


Provisioning File Reference N 


12.50 


O 


N 


FN 


Text String (Gateway/Proxy Identity) 


12.15 


O 


N 


G 


Alpha identifier (user confirmation phase) - 


12.2 


o • 


N 


H 


Icon identifier (user confirmation phase) 


12.31 


O 


N 


I 



If the URL data object is provisioned the URL value shall take precedence over any other URC value. 



BNSDOCID: <XP 2222021 A _!_> 



ETSI 



(GSM 11.14 version 8.3.0 Release 1999) 



53 



ETSI TS 101 267 V8.3.0 (2000-08) 



If Provisioning File Reference data object is present in the command then it shall take precedence over Bearer and 
Proxy Identity. If several Provisioning File References are present in the same command the information in the first 
reference shall take precedence. 

Gateway/Proxy Identity is a text string (cf. 12.15) which gives to the mobile the name/identity of the Gateway/Proxy to 
be used for connecting to the URL 

The ME shall ask the user for confirmation using the Alpha Identifier/Icon Identifier (user confirmation phase) if 
present, when it receives a LAUNCH BROWSER command which requests the existing browser session connected to a 
new URL or to terminate a browser session. 

6.6.27 OPEN CHANNEL 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E+F+G+H+l+J+K+L+M+N+O+P+Q) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


O 


N 


C 


Icon identifier 


12.31 


O 


N 


D 


Address 


12.1 


c 


Y 


E 


Called party subaddress 


12.3 


0 


N 


F 


Duration 1 


12.8 


0 


N 


G 


Duration 2 


12.8 


0 


N 


H 


Bearer description 


12.52 


M 


Y 


I 


Buffer size 


12.55 


M 


N 


J 


URL (Access Point address) 


12.48 


O 


N 


K 


Other address (local address) 


12.58 


O 


N 


L 


Text String (User login) 


12.15 


O 


N 


M 


Text String (User password) 


12.15 . 


O 


N ■ 


N 


SIM/ME interface transport level 


12.59 


O 


N 


O 


URL (data destination address) 


12.48 


C 


Y . 


P 


Other address (data destination address) 


12.58 


C 


Y 


Q 



The Address is requested for CS bearer, for other bearer it is ignored. If the parameter is not present, the mobile uses the 
default address mobile configuration if any. 

The Subaddress may be requested for CS bearer only, for other bearer it is ignored. If the called party subaddress is not 
present, the ME shall not provide a called party subaddress to the network. 

Duration I indicates the duration of reconnect on tries. If Duration 1 is not present, the SIM imposes no restrictions on 
the ME. 

Duration 2 indicates the timeout value before the ME releases the link if there is no data exchanged on the link.If 
duration 2 is not present the link is never released automatically by the ME. 

The Access point address may be requested for GPRS bearer only. For other bearers, it shall be ignored. The Access 
point address parameter is a URL (see 12.48) which provides information to the ME necessary to identify the entity 
which provides interworking with an external network. If the parameter is not present, the mobile may use the default 
access point address mobile configuration or subscription value. 

The local address parameter (see 12.58) provides information to the ME necessary to identify the local device (i.e. it 
provides an IP address). If local address length is null, dynamic local address is required. If parameter is not present, the 
mobile may use the mobile default local address configuration. 

User login parameter is a text string (see 12. 15) which provides information to the ME necessary to answer 
authentication challenge by supplying access login (e.g. it may provide PPP login). If parameter is not present, the 
mobile uses default login configuration if any. If no authentication challenge is requested, the user login parameter shall 
be ignored. 
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User password parameter is a text string (sec 12. 15) which provides information to the ME necessary to answer 
authentication challenge by supplying access password (e.g. it may provide PPP password). If the parameter is not 
present, the mobile may use the default password configuration if any. If no authentication challenge is requested, the 
user password parameter shall be ignored. 

If the SIM/ME interface transport level is present in the command, then the ME shall provide the requested transport 
layer protocols under the channel and shall use this object containing a set of parameters required to make the transport 
connection If the parameter is not present, the SIM/ME interface is the bearer level (serial link or packet link as AT 
command defined in TS 27.007 [27]). The data that will be received/sent from the SAT to the transport layer is a SDU 
that will be received/transmitted in the Transport-PDU. • 

The Data destination address is the end point destination address of sent data. This data destination address is requested 
when a SIM/ME interface transport is present, otherwise it is ignored. The data destination address may be a URL or a 
data network address. If a URL and a data network address is present, the URL shall be ignored. 



BNSDOC1D: <XP 2222021 A_U> 



ETSf 



(GSM 11.14 version 8.3.0 Release 1 999) 55 ETSI TS 1 01 267 V8.3.0 (2000-08) 

6.6.28 CLOSE CHANNEL 



Description 


Section 


M/U 


Min 


Lengtn 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


O 


N 


C 


Icon identifier 


12.31 


O 


N 


D 



6.6.29 RECEIVE DATA 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D-f E) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


O 


N 


C 


Icon identifier 


12.31 


O 


N 


D 


Channel data length 


12.54 


M 


Y 


E 



6.6.30 SEND DATA 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y . 


1 


Length (A+B+C+D+E+F) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


O 


N 


C 


Icon identifier 


12.31 


O 


N 


D 


Channel data length 


12.54 


M 


Y 


E 


Channel data 


12.53 


M 


Y 


F • 



6.6.31 GET CHANNEL STATUS 



Description 


Section 


M/O 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 




M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 



6.7 Command results 

Once the ME has made its attempt to execute a proactive command from the SIM, the ME shall inform the SIM of the 
success or otherwise of that command, by using TERMINAL RESPONSE. This message gives the command details, 
including the number of the command (see subclause 6.5. 1), a general result, and sometimes more specific information. 

Three overall categories of results arc defined: 

- Command performed successfully. This is returned by the ME for every successful command; 

- Temporary problem with executing command. This is further defined below, but generally these indicate to the 
SIM that it is worth trying again later; 

- Permanent problem with executing command. These are further defined below, but generally indicate that the 
same command will end in the same result if repeated during the same GSM session. 

Successful commands are further defined as: 
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- Command performed successfully. There were no problems; 

. Command performed with partial comprehension. Here the MB receives a command with one or more SIMPLE- 
TLV data objects that are unrecognized or unexpected, all of which do not have their ' ~™^^ 0 " 
flag set (subclause 13.3), but the parent BER-TLV data object still has the minimum set of SIMPLE-TLV data 
objects required to perform the command; 

Command performed, with missing information. The ME received at least the minimum set of component parts, 
but did not receive all of the parts that it believed mandatory for the SIM to send; 

Command performed, but modified by call control. This is sent by the ME to indicate that call control modified 
the type of request indicated in the proactive command, and that the action requested by call control was 
performed successfully; 

- Command performed with modification. This is sent by the ME to indicate that it is unable to process the 
command using the exact parameters provided by the SIM. The command is processed with the best possible 
parameters. 

Temporary problems are further defined as: 

- ME is currently unable to process the command. Specific causes for this are: 

- the screen is busy; 

- ME currently busy on a call; 

- ME currently busy on SEND DTMF operation; 

- ME currently busy on SS transaction; 

- ME currently busy on USSD operation;- 

- no service is currently available; 

- access control class barred on serving network; 

- no radio resource currently available; 

- not in speech call. 

If none of these can be made to apply, a "no cause can be given" value can be used. 

- Network is currently unable to process the command. Specific cause values are the cause values given by the 
network, as defined in GSM 04.08 [8]. 

The user did not accept the call set-up request. This is where the ME alerts the user before setting up a call, and 
the user either rejected or did not accept the "call". 

- The user cleared down the call, before the call connected (CONNECT received from network, as defined in 
GSM 04.08 [8]) or before the network released the call. 

- Action in contradiction with the current timer state. This is where the SIM requests an action for a timer to be 
taken by the ME and the state of the timer does not allow that action. 

- Interaction with call control by SIM, temporary problem. This is sent by the ME to indicate that call control 
modified the type of request indicated in the proactive command, and that the action requested by call control 
encounters a temporary problem. 

Permanent problems are further defined as: 

Command is beyond MEs capabilities. This is sent by the ME when it understands what the SIM is asking it to 
do, but does not have the capability to do it, e.g. ME which only supports SMS asked to set up a call. 

- Command type not understood by ME. This is sent by the ME when the SIM sends a command with the Type of 
Command byte set to a value the ME docs not know. This is to allow future expansion of commands. 

Command data not understood by ME. This is sent by the ME when the command type is understood by the ME, 
but the related data object(s) are not, e.g. reserved values have been included in a data object, or one or more 
unknown SIMPLE-TLV data objects have a "comprehension required" tag. 

SS Return Error This is given to the SIM when the network returns a SS error in response to a previous SS 
command. Specific cause values are the same as given by the network in the Return Error message. 
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- USSD Return Error. This is given to the SIM when the network returns a USSD error in response to a previous 
USSD command. Specific cause values are the same as given by the network in a Return Error message. 

- SMS RP-ERROR. This is given to the SIM when the network returns an error in response to the ME trying to 
send a short message. Specific cause values are the same as the cause value of RP-Cause in an RP-ERROR 
message. 

- Error, required values are missing. This is given when the command type is understood by the ME, but it does 
not receive the minimum set of SIMPLE-TLV data objects that it requires to perform the command. These 
components are shown by the "Min" column in the command structure definitions. 

- Interaction with call control by SIM or MO short message control by SIM, permanent problem. This is sent by 
the ME to indicate that : 

- call control by SIM does not allow the action corresponding to the proactive command or 

- call control by SIM has modified the type of request indicated in the proactive command and that the action 
requested by call control encounters a permanent problem. 

Specific cause values for this are : 

- action not allowed; 

- the type of request has changed; 

If none of these can be made to apply, a "no cause can be given*' value can be used. 

6.8 Structure of TERMINAL RESPONSE 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [20]. Length (A+B+C+D+E+F+G+H+I4-J+K+L+M+N+P+Q+ 
r+S+T+U+V) is indicated by P3 of the header. 

Command parameters/data: 
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Description 


Section 


M/O 


Min 


Length 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


N' 


B 


Result 


12.12 


M 


Y 


C 


Duration (only required in response to a 
POLL INTERVAL proactive command) 


12.8 


M/O 


Y/N 


D 


Text string (only required in response to a 
GET INKEY or GET INPUT or SEND USSD 
proactive command) 


12.15 


M/O 


Y/N 


E 


Item identifier (only required in response to 
SELECT ITEM proactive command) 


12.10 


M/O 


Y/N 


F, 


Local information (only required in response 
to PROVIDE LOCAL INFORMATION 


12.19, 12.20, 
12.22, 12.29, 
12.39, 12.45 
& 12.46 


M/O 


Y/N 


G 


Call control requested action (only required 
if call control by SIM has modified a 
proactive cornmcii iu oc i ur oam_i_, o^imu/ 
SS or SEND USSD in another type of 
request). 


12.30 


M/O 


Y/N 


H 


Result data object 2 (only required if call 
control by SIM has modified a proactive 
command SET UP CALL, SEND SS or 
SEND USSD in another type of request). 


12.12 


M/O 


Y/N 


I 


uard reader status (oniy requirea in 
response to GET READER STATUS 
command). According to the requested j 

infnrm^inn nno OarH roarfpr Qtatn^ nfaisct 
inTOrrTlallOl I, UMc wdlU f cdUtM oiaiuo uujgoi 

for each card interface reported or one Card 
reader identifier object is required. 

/nnl\/ if Hp.<;q "a" i<5 < ^LlDDO^tedV' ,, 


1 2 33 1 2 57 


M/O 


N 


j 0 + ... + j n 
or J 


Card ATR (only required in response to 
POWER ON CARD). 

/ r\n\\/ if r'lacc "p" i<; 'siinnortfidi 


12.33 


M/O 


N 


K 


R-APDU (only required in response to 
PERFORM CARD APDU). 

/Anlw if r>tacQ "p" i«5 ^nooortGd^ 


12.36 


M/O 


N 


L 


Timer identifier (only required in response 
to a TIMER MANAGEMENT proactive 

QUI 1 II t lal IU/ 


12.37 


M/O 


Y/N 


M 


Timer value (only required in response to a 
TIMER MANAGEMENT proactive 
command) 


12.38 


M/O 


Y/N 


N 


AT Doen^nco fnnlv roni lirpH in rp^nonse tO 
Ml riSSpUllofc; ^VJlliy it?mJiicu ii i icopui iw 

RUN AT COMMAND proactive command) 
(only if class "b" is supported) 


12.41 


M/O 


Y/N 


P 


Text string2 (only required if call control by 
SIM has modified the proactive command 
SET UP CALL or SEND SS into a USSD 
request) 


12.15. 


M/O 


Y/N 


Q 


Channel data (only required in response to 
RECEIVE DATA) 

(only if class "e M is supported) 


12.53 


M/O 


Y/N 


R 
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Description 


Section 


M/O 


Min 


Length 


Channel status (only required in response 

tr> f^FT PHANNFI ^TATl 19 nr OPFNI 

IU OC 1 vllrtlNINCL O 1 n 1 \J O Ul vruIN 

CHANNEL proactive command) 
(only if class n e" is supported) 


12.56 


WO 


Y/N 


S 0 + ... +S n 


Channel data length (only required in 

rocnnnco \r\ RFHFIVF DATA nr ^FNIO 

DATA proactive command) 
(only if class "e" is supported) 


12.54 


WO 


Y/N 


T 


Rparpr rip^rrintion fonlv reouired in 
response to OPEN CHANNEL proactive 
command) 

(only if class "e" is supported) 


12.52 


wo 


Y/N 


u 


Buffer size (only required in response to 
OPEN CHANNEL proactive command) 
(only if class "e" is supported) 


12.55 


wo 


Y/N 


V 



- Command details: this data object shall be identical to the command details data object (including the 
comprehension required flag) given by the SIM in the proactive command to which the ME is giving the result. 

If the ME has not received a valid Command number, all Command Details object values shall be set to '00' and 
the Result shall indicate an error. 

If the failure is caused by a problem on the transmission layer, the ME shall respond with "temporary problem" 
("ME currently not able to process command"). If not, the ME shall respond with "permanent problem" (either 
"command not understood by ME" or "Error required values are missing"). 

The SIM shall interpret a Terminal Response with a command number '00' as belonging to the last proactive 
command having been sent to the ME. 

i 

- Device identities: the ME shall set the device identities to: 

Source: ME - \ 

Destination: SIM 

- Result: This data object holds the result of the proactive SIM command. ?\ 

■ " i 

- Duration: When the ME issues a successful TERMINAL RESPONSE for a POLL INTERVAL command, it shall 
state the polling interval it will be using in the Duration data object. All other types of TERMINAL RESPONSE 
do not need to include Duration. If one is included by the ME, the SIM shall ignore it. 
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Text string When the ME issues a successful TERMINAL RESPONSE ('OX' result value - refer to subclause 
12 12) for°a GET INKEY or GET INPUT or SEND USSD command, it shall supply the single character or the 
character string entered by the user in the Text string data object, or the text returned within the Return Result 
message from the network for the USSD command, no matter what type of string was entered. Ail other types ol 
TERMINAL RESPONSE do not need to include Text string. If one is included by the ME, the SIM shall ignore 
it When the ME issues a successful TERMINAL RESPONSE ('0X ( result value.- refer to subclause 12.12) for a 
GET INKEY ("Yes/No") command with command qualifier set to "Yes/No", it shall supply the value '01 when 
the answer is "positive" and the value '00' when the answer is "negative" in the Text string data object. 

When the ME issues a successful TERMINAL RESPONSE ('OX' result value - refer to subclause 12.12) for a 
GET INPUT command to which the user has made an empty input (i.e. if the user does not enter any character), 
the ME shall indicate this by means of either a null text string (see subclause 12.15 for the coding of this object), 
or by means of a Text string object with Length = '01', and a Value part consisting of a data coding scheme only. 

NOTE: The notion of empty input is different from the general result 'no response from user' (see 
subclause 12.12). The latter event is typically caused by a timeout in the MMI, whereas an 
empty input requires an acknowledgement from the user. 

Item identifier: When the ME issues a successful TERMINAL RESPONSE ('OX' result value - refer to subclause 
V 12) for a SELECT ITEM command, it shall supply the identifier of the item selected by the user m the Item 
identifier data object. If the ME issues a TERMINAL RESPONSE with result "Help information required by the 
user" for a SELECT ITEM command, it shall supply the identifier of the item for which the user is requiring help 
information. All other types of TERMINAL RESPONSE do not need to include Item identifier. If one is 
included by the ME, the SIM shall ignore it. 

Local information. When the ME issues a successful TERMINAL RESPONSE for a PROVIDE LOCAL 
INFORMATION command, it shall supply the requested local information. 

Where the SIM has requested location information, TERMINAL RESPONSE shall contain the location 
information data object. All other types of TERMINAL RESPONSE do not need to include location 
information. If one is included by the ME, the SIM shall ignore it. 

Where the SIM has requested the IMEI, TERMINAL RESPONSE shall contain the 1MEI data object. All 
other types of TERMINAL RESPONSE do not need to include IMEI information. If one is included by the 
ME, the SIM shall ignore it. 

Where the SIM has requested the Network Measurement Results the TERMINAL RESPONSE shall contain 
the NMR data object and the BCCH channel list data object. All other types of TERMINAL RESPONSE do 
not need to include the NMR information or the BCCH channel list. If one is included by the ME, the SIM 
. shall ignore it. ' ' * 

Where the SIM has requested the date, time and time zone the TERMINAL RESPONSE shall contain the 
Date-Time and Time zone data object. All other types of TERMINAL RESPONSE do not need to include the 
Date-Time and Time zone information. If one is included by the ME, the SIM shall ignore it. 

- Where the SIM has requested the currently used language, the TERMINAL RESPONSE shall contain the 
Language data object. All other types of TERMINAL RESPONSE need not to include the Language 
information. If one is included by the ME, the SIM shall ignore it. 

Where the SIM has requested the Timing Advance, the TERMINAL RESPONSE shall contain the Timing 
Advance data object. All other types of TERMINAL RESPONSE do not need to include the Timing Advance 
information. If one is included by the ME, the SIM shall ignore it. 

- Call control requested action. When the ME issues a TERMINAL RESPONSE for a proactive command SET 
UP CALL, SEND SS or SEND USSD which has been modified by call control by SIM in another type of 
request, it shall supply the response data given in response to the ENVELOPE (CALL CONTROL). 

Result data object 2. When the ME issues a TERMINAL RESPONSE for a proactive command SET UP CALL, 
SEND SS or SEND USSD which has been modified by call control by SIM in another type ot request, it shall 
supply the Result data object it would have supplied for the proactive command equivalent to the action 
requested by call control, and given in the Call control request data element. 
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- Card reader status (if class "a" is supported). When the ME issues a successful TERMINAL RESPONSE for a 
CARD READER STATUS command, it shall supply the requested readers information. 

- Where the SIM has requested the card reader status, TERMINAL RESPONSE shall supply the status of each 
card reader in n consecutive Card reader status data objects, where n is the card reader count. All other types 
of TERMINAL RESPONSE do not need to include Card reader status. If one is included by the ME, the SIM 
shall ignore it. 

• - Where the SIM has requested the card reader identifier, TERMINAL RESPONSE shall supply the identifier 
of the requested card reader identifier All other types of TERMINAL RESPONSE do not need to include 
Card reader identifier. If one is included by the ME, the SIM shall ignore it. 

""- Card ATR (if class "a" is supported): When the ME issues a successful TERMINAL RESPONSE for a POWER 
ON CARD command, it shall supply the ATR returned by the addressed card in the Card ATR data object. All 
other types of TERMINAL RESPONSE do not need to include Card ATR. If one is included by the ME, the SIM 
shall ignore it. 

- R-APDU (if class "a" is supported): When the ME issues a successful TERMINAL RESPONSE for a 
PERFORM CARD APDU command, it shall supply the response data and status words in the R-APDU data 
object. All other types of TERMINAL RESPONSE do not need to include R-APDU. If one is included by the 
ME, the SIM shall ignore it. 

- Timer identifier: When the ME issues a successful TERMINAL RESPONSE for a TIMER MANAGEMENT, it 
shall state in the timer identifier data object the identifier of the timer to which this command applies. All other 
types of TERMINAL RESPONSE do not need to include timer identifier data object. If one is included by the 
ME, the SIM shall ignore it. 

- Timer value: When the ME issues a successful TERMINAL RESPONSE for a TIMER MANAGEMENT 
command with command qualifier indicating 'deactivate' or 'get the current value of the timer', it shall state in the 
timer value data object the current value of the timer. All other types of TERMINAL RESPONSE do not need to 
include timer value. If one is included by the ME, the SIM shall ignore it. 

- AT Response (if class "b" is supported): When the ME issues a successful TERMINAL RESPONSE for a RUN 
AT COMMAND command, it shall supply the following information. 

- The TERMINAL RESPONSE shall contain the AT Response (as defined in section 12.40). If the AT 
Response is included in a TERMINAL RESPONSE to a different command, it shall be ignored by the SIM. 

- Text string2: When the ME issues a successful TERMINAL RESPONSE for a proactive command SET UP 
CALL or SEND SS which has been modified by "call control" by SIM into a USSD request ('05' result value), it 
shall supply the Text string2. The Text string2 shall contain the text returned within the Return Result message 
from the network for the USSD response. Text string2 is equivalent to the Text string in the Terminal Response 
to a SEND USSD command. 

- Channel data (if class "c" is supported): When the ME issues a successful TERMINAL RESPONSE for a 
RECEIVE DATA command it shall supply the following information. 

- The TERMINAL RESPONSE shall contain the Channel data data object (as defined in section 12.53). If this 
data object is included in a TERMINAL RESPONSE to a different command, it shall be ignored by the SIM. 

- Channel status (if class "e" is supported): When the ME issues a successful TERMINAL RESPONSE for a GET 
CHANNEL STATUS or an OPEN CHANNEL command, it shall supply the following information. 

- In response to a GET CHANNEL STATUS, TERMINAL RESPONSE shall contain as many Channel status 
data object (as defined in section 12.56) as there are available channel. In response to a OPEN CHANNEL, 
TERMINAL RESPONSE shall contain a Channel status data object. If this data object is included in a 
TERMINAL RESPONSE to a different command, it shall be ignored by the SIM. 

- Channel data length (if class "e" is supported): When the ME issues a successful TERMINAL RESPONSE for a 
RECEIVE DATA command or a SEND DATA, it shall supply the following information. 

- The TERMINAL RESPONSE shall contain the Channel data length data object (as defined in section 12.54). 
If this data object is included in a TERMINAL RESPONSE to a different command, it shall be ignored by the 
SIM. 
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- Bearer description (if class V is supported): When the ME issues an unsuccessful TERMINAL RESPONSE or 
" a successful TERMINAL RESPONSE for an OPEN CHANNEL command, it shall supply the following 

information. 

- The TERMINAL RESPONSE shall contain the Bearer description data object (as defined in section 1 2.52). 
If this data object is included in a TERMINAL RESPONSE to a different command, it shall be ignored by the 
SIM. 

- Buffer size (if class V is supported): When the ME issues an unsuccessful TERMINAL or a successful 
TERMINAL RESPONSE for a OPEN CHANNEL command, it shall supply the following information. 

- The TERMINAL RESPONSE shall contain the Buffer size data object (as defined in section 1 2.55). If this 
data object is included in a TERMINAL RESPONSE to a different command, it shall be ignored by the SIM. 

Under no circumstances shall the SIM wait indefinitely for a TERMINAL RESPONSE. 

Any future additional SIMPLE-TLV objects shall be included as Min = N and comprehension not required. This will 
ensure that any proactive command will end in a predictable way. 

Response parameters/data: None. 

6.9 Proactive SIM session and ME display interaction 

During a proactive session the ME display shall be refreshed by any display data contained in the first and each 
subsequent proactive command. The refresh shall occur once the ME has retrieved the proactive command using the 
Fetch instruction, following the proactive command pending status response. 

If no proactive command is pending (status response of '90 00' following the Terminal Response), then the session 
releases the display back into ME control. If this session was terminated in a backwards move, and the session was 
initiated from an Envelope command containing a Menu Selection, it is recommended that the display returns to the 
Setup Menu. 

If the text is to be sustained, the ME shall display the text of applicable DISPLAY TEXT commands beyond the sending 
of the TERMINAL RESPONSE and possibly beyond the end of the proactive session. 

6.10 Handling of unknown, unforeseen and erroneous messages 
6.10.1 General 

The procedures described in this subclause apply to the BER-TLV and SIMPLE-TLV data objects described in the 
present document. The purpose of this subclause is to allow greater flexibility in future versions of this document, and a 
greater predictability across different versions of this standard. 

The procedures described here specify how the ME and SIM shall behave when they receive a proactive command or 
response that is not fully compliant with the standards by which it was designed. A response will be made to the SIM by 
means of the "general result" field of the "result 1 * 

If the ME sends a FETCH or TERMINAL RESPONSE to the SIM that contains values that the SIM does not 
- understand, then the SIM shall issue the appropriate SW1 / SW2 error response. The current proactive transaction shall 
be considered complete and neither the ME or the SIM shall take no further action with regard to it. In this case, unless 
the "General result" is "command performed..." then the SIM shall assume that the command was not carried out and 
that a permanent error exists with regard to that particular proactive command. If the command was performed, but the 
"additional information on result" field was not understood, then the SIM may attempt the command again at a later 
stage in the current GSM session. ■ 

If the SIM has enough information to proceed (i.e. it has received all the data objects of the Minimum set) then it shall 
do so. 
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6.10.2 Message too short 

Any information received that is not a complete tag and length shall be ignored. 

6.10.3 Missing minimum information 

If a message is received that does not have all the mandatory elements in it, then if all of the minimum set elements are 
present then the receiver shall complete the command and report "command performed, with missing information". 

If the minimum set of elements is not complete, then the ME shall respond with "Error, required values are missing". 

6.10.4 Unknown Tag value 

If a BER-TLV object is received that has a tag that is understood, but contains SIMPLE-TLV components that have 
unknown tags, then provided the minimum set condition is fulfilled, the "comprehension required" bit of the tag shall 
determine how the receiving entity behaves. 

If the comprehension required flag in an unknown tag is set to V, and the ME either does not recognize or is not 
expecting one or more of the SIMPLE-TLV objects in the message, then it shall respond with "Command data not 
understood by ME". 

If the comprehension required flag is set to '0', then the ME shall read the length field that follows and ignore that object. 
In this case the ME will be able to carry out the command without the SIMPLE-TLV components that it cannot 
understand. It shall respond with "command performed with partial comprehension ". 

6.10.5 Unexpected Tag value 

If a BER-TLV object is received that contains elements that have recognisable tags, but which where not expected in the 
context of this message (for example, the ME sees SMS TDPU tag as part of TEXT FOR DISPLAY), then is shall 
discard that element. It shall then proceed as described for Unknown Tag values. 

If a received object has a tag that has already been received, then the first instance shall be used and any subsequent 
instances shall be discarded. 

6.10.6 Length errors 

If the total lengths of the SIMPLE-TLV data objects are not consistent with the length given in the BER-TLV data 
object, then the whole BER-TLV data object shall be rejected. The result field in the TERMINAL RESPONSE shall 
have the error condition "Command data not understood by ME". 

If the length of the BER-TLV data object is shorter than the length of the response data, the ME shall ignore response 
data following the complete BER-TLV data object. If the length of the BER-TLV data object is longer than the length of 
the response data, then sections 6.10.2. and 6. 10.3 apply. 

6.1 0.7 Contents not understood 

If the contents of a SIMPLE-TLV data object contains a field with a value that is defined as reserved, then the whole 
SIMPLE-TLV data object shall be considered as invalid. It will then depend on the "comprehension required" bit of the 
relevant tag as to whether the whole BER-TLV data object shall be rejected, or whether that particular SIMPLE-TLV 
data object shall be ignored. 

If the contents of a BER-TLV object contains RFU bits or bytes, then these shall be ignored. 

6.1 0.8 Extended length data objects 

If a SIMPLE-TLV data object has a length longer than expected (i.e. more information has been added), then the 
receiver shall ignore this extra information to the end of the object. The end of the object shall be found by looking at 
the "length" field of that object. 
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NOTE: If comprehension of the extra bytes is required/this can be achieved by the use of a reserved coding in an 
earlier field. 4 

6.1 1 Proactive commands versus possible Terminal response 

The following table shows for each proactive command the possible terminal response returned (marked by a "•" 
character). 
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7 Data download to SIM 

7.1 SMS-PP data download 
7.1.1 Procedure 

If the service "data download via SMS Point-to-point" is allocated and activated in the SIM Service Table (see 
GSM li.il [20]), then the ME shall follow the procedure below: 

- When the ME receives a Short Message with: 

protocol identifier = SIM data download, and 
data coding scheme = class 2 message, 

or 

when the ME receives a Short Message with: 

protocol identifier=ANSI- 1 36 R-DATA (see 3G TS 23.040 [30]) and 

data coding scheme = class 2 message, and the ME chooses not to handle the message ( e.g. MEs not 
supporting EGPRS over TIA/EIA-136 do not need to handle the message), 

then the ME shall pass the message transparently to the SIM using the ENVELOPE (SMS-PP DOWNLOAD) 
command as defined below. 

- The ME shall not display the message, or alert the user of a short message waiting. 

- The ME shall wait for an acknowledgement from the SIM. 

- If the SIM responds with '90 00', the ME shall acknowledge the receipt of the short message to the network using 
an RP-ACK message. 

- If the SIM responds with '93 00', the ME shall either retry the command or send back an RP-ERROR message to 
the network with the TP-FCS value indicating 'SIM Application Toolkit Busy' (see GSM 03.40 [6]). ; 

V, 

- If the SIM responds with '9F XX', the ME shall use the GET RESPONSE command to get the response data. The 
response data from the SIM will be supplied by the ME in the TP-User-Data element of the RP-ACK message it 
will send back to the network (see GSM 03.40 [6] and GSM 04. 1 1 [9]). The values of protocol identifier and 
data coding scheme in RP-ACK shall be as in the original message. 

IF the SIM responds with '6F XX', the ME shall send back an RP-ERROR message to the network with the TP- 
FCS value indicating "SIM data download error". The values of protocol identifier and data coding scheme in 
RP-ERROR shall be as in the original message. 

NOTE: The preferred way for a SIM application to indicate a Data Download error is by using the specific code 
'9E XX as desribed in the following bullet point. 

- If the ME has indicated in TERMINAL PROFILE that it supports the status word '9E XX and if the SIM 
responds with '9E XX', the ME shall use the GET RESPONSE command to get the response data. The response 
data from the SIM will be supplied by the ME in the TP-User-Data element of the RP-ERROR message it will 

■ send back to the network (see GSM 03.40 [6] and GSM 04. 1 1 [9]). The values of protocol identifier and data 
coding scheme in RP-ERROR shall be as in the original message. The value of the TP-FCS element of the RP- 
ERROR shall be "SIM data download error". 

If the service "data download via SMS-PP" is not allocated and activated in the SIM Service Table, and the ME receives 
a Short Message with the protocol identifier = SIM data download and data coding scheme = class 2 message, then the 
ME shall store the message in EF SMS in accordance with GSM 11.11 [20J. 

NOTE: MEs not supporting SIM Application Toolkit are likely to store data download messages in EF SMS , as if 
they were normal short messages. 
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7.1 .2 Structure of ENVELOPE (SMS-PP DOWNLOAD) . 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [20]. 
Command parameters/data: 



Description 


Section 


M/O 


Min 


Length 


SMS-PP download tag 


13.1 


M 


Y 


1 ! 


Length (A+B+C) 




M 


Y 


1 or 2 


Device identities 


12.7 


M 


Y 


A 


Address 


12.1 


0 


N 


B 


SMS TPDU (SMS-DELIVER) 


12.13 


M 


Y 


C 



- Device identities: the ME shall set the device identities to: 

Source: Network 
Destination: SIM 

- Address: The address data object holds the RP_Originating_ Address of the Service Centre (TS-Service-Centre- 
Address), as defined in GSM 04. 1 1 [9]. 

Response parameters/data: 

It is permissible for the SIM not to provide response data. If the SIM responds with '90 00' then no response parameter 
shall be available, otherwise the SIM shall respond with *9F XX* or '9E XX' and the following data is returned: 



Byte(s) 


Description 


Length 


1-X (XS128) 


SIM Acknowledgement 


X 



7.2 Cell Broadcast data download 

7.2.1 Procedure 

If the service "data download via SMS-CB M is allocated and activated in the SIM Service Table (see GSM 1 1 . 1 1 [201), 
then the ME shall follow the procedure below: 

- When the ME receives a new Cell Broadcast message, the ME shall compare the message identifier of the Cell 
Broadcast message with the message identifiers contained in EF CBMID . 

- If the message identifier is found in EF CBM1D , the cell broadcast page is passed to the SIM using the 
•ENVELOPE (CELL BROADCAST DOWNLOAD) command, defined below. The ME shall not display the 

message. 

- If the message identifier of the incoming cell broadcast message is not found in EF CBMID , then the ME shall 
determine if the message should be displayed, by following the procedures in GSM 03.41 [7] and 

GSM 11.11 [20]. 

The ME shall identify new cell broadcast pages by their message identifier, serial number and page values. 

7.2.2 Structure of ENVELOPE (CELL BROADCAST DOWNLOAD) 

Direction: ME to SIM 

The command header is specified in GSM 11.11- [20]. 
Command parameters/data: 
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Description 


Section 


M/O 


Min 


Length 


Cell Broadcast Download tag 


13.1 


M 


Y 


1 


Length (A+B) 




M 


Y 


1 or 2 


Device identities 


12.7 


M 


Y 


A 


Cell Broadcast page 


12.5 


M 


Y 


. B 



- Device identities: the ME shall set the device identities to: 
Source: Network 
Destination: SIM 

Response parameters/data: None for this type of ENVELOPE command. 



8 Menu Selection 

A set of possible menu options can be supplied by the SIM using the proactive command SET UP MENU. If the SIM 
has sent this command, and the user subsequently chooses an option or, the user requests help on it, the ME informs the 
SIM using this procedure. 

8.1 Procedure 

If the service "menu selection" is allocated and activated in the SIM Service Table (see GSM 1 1 . 1 1 [20]), then the ME 
shall follow the procedure below. 

- When the ME receives a menu selection from one of the menu items defined by a "SET-UP MENU" command 
issued previously by the SIM, or the user has indicated the need. to get help information on one of these menu 
items, then it shall pass the identifier of the selected menu item to the SIM using the ENVELOPE (MENU 
SELECTION) command, as defined below. 

8.2 Structure of ENVELOPE (MENU SELECTION) 

Direction: ME to SIM ' \ 

The command header is specified in GSM 11.11 [20]. 
Command parameters/data: 



Description 


Section . 


M/O 


Min 


Length 


Menu Selection tag 


13.1 


M 


Y 


1 


Length (A+B+C) 




M 


Y 


1 or 2 


Device identities 


12.7 


M 


Y 


A 


Item identifier 


12.10 


M 


Y 


B 


Help request 


12.21 


O 


N 


C 



- Device identities: the ME shall set the device identities to: 

Source: Keypad 
Destination: SIM 

- Help request: inclusion of this data object depends upon whether the user actually selected the named menu item 
or just requested help information on it. If the user actually selected the menu item, this data object shall not be 
included. If the user indicated the need to get help information on the menu item, this data object shall be 
included. 

Response parameters/data: None for this type of ENVELOPE command. 
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Coding of byte 4: 

- '00' = No further info can be given 

- '01' = Rx buffer full 

- '02' = Rx buffer empty 

- '03' = Tx buffer full 

- W = Tx buffer empty 

- '05' = Link dropped 

all other values are reserve'd for future use 

1 2.57 Card reader identifier 

This subclause applies only if class "a" is supported. 



Coding : 

The identifier of card reader is coded in hexadecimal. 



Byte(s) 


Description 


Length \ 


■ 1 


Card reader identifier tag 


1 


2 


Length (X) 


1 


3 to (X+2) 


Identifier of card reader 


X 



12.58 Other Address 



Byte(s) 


Description 


Length 


1 


Other address tag 


1 


2 


Length (X) 


1 


3 


Type of address 


1 


4 to (4 + X-1) 


Address 


X 



A null Local address shall be coded with Length = '00\ and no Value part. In that case, the ME shall request a dynamic 
address. 

Coding of Type of address: according to packet data protocol address in GSM 04.08 [8]. 
'21' = IPv4 address 
'97' = IPv6 address 
'others' = reserved 

Codin* of address: according to packet data protocol address in GSM 04.08 [8]. 

If type of address indicates IPv4, the Address information in octet 4 to octet 7 contains the IPv4 address. Bit 8 
of octet 4 represents the most significant hit of the IP address and bit 1 of octet 7 the least significant bit . 

If type of address indicates IPv6, the Address information in octet 4 to octet 1 9 contains the IPv6 address. Bit 
8 of octet 4 represents the most significant bit of the IP address and bit 1 of octet 19 the least significant bit. 



1 2.59 SIM/ME interface transport level 

This subclause applies only if class "c" is supported. 



Byte(s) 


Description 


Length 


1 


SIM/ME interface transport level tag 


1 


2 


Length (X+1) 


1 


3 


Transport protocol type 


1 


4 to 5 


Port number 


2 
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- Transport protocol type coding: 

- 'Or : UDP (as defined in RFC 768 [33]) 

- '02' : TCP (as defined in RFC 793 [34]) 
all other value are reserved 

- Port number coding: integer 



13 Tag values 

This clause specifies the tag values used to identify, the BER-TLV and SIMPLE-TLV data objects used in this 
specification. 

13.1 BER-TLV tags in ME to SIM direction 



Description 


Length of tag 


Value 


SMS-PP'download tag 




r D1' 


Cell Broadcast download tag 




'D2' 


Menu Selection tag 




'D3* 


Call control tag 




'D4' 


MO Short message control tag (if (MOSMcontrol is 
supported) 




'D5' 


Event download tag 




'D6' 


Timer expiration 




'D7' 


Reserved for TIA/EIA-136 




'DP 


BER-TLV tags in SIM TO ME direction 


Description 


Length of tag 


Value 


Proactive SIM command tag 


1 


'DO' 



13.3 SIMPLE-TLV tags in both directions 



8 


7|6|5|4|3|2|1 


CR 


Tag value 



CR: Comprehension required for this object. 

Unless otherwise stated, for SIMPLE-TLV data objects it is the responsibility of the SIM application and the ME to 
decide the value of the CR flag for each data object in a given command. 

Handling of the CR flag at the receiving entity is described in subclause 6.10. 



CR 


Value 


Comprehension required 


1 


Comprehension not required 


0 
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